linux-uvc-devel — Linux UVC development

[linux-uvc-devel] 04f2:b2db is supported, with non-functional second video device

[Kevin L. <ke...@ke...>]

Hi all,

The ThinkPad T430 includes a "Chicony Electronics Co., Ltd." "Integrated
Camera" (04f2:b2db).  The camera works well with uvcvideo, but does not
currently appear on the Supported Devices list.[1]  There are two,
possibly related, oddities worth mentioning:

First, there are a few warnings printed when uvcvideo is loaded:

uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b2db)
uvcvideo 3-1.6:1.0: Entity type for entity Extension 4 was not initialized!
uvcvideo 3-1.6:1.0: Entity type for entity Extension 3 was not initialized!
uvcvideo 3-1.6:1.0: Entity type for entity Processing 2 was not initialized!
uvcvideo 3-1.6:1.0: Entity type for entity Camera 1 was not initialized!

Second, uvcvideo creates two video devices (video0 and video1):

$ readlink /sys/class/video4linux/video*
../../devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.6/3-1.6:1.0/video4linux/video0
../../devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.6/3-1.6:1.0/video4linux/video1

`mpv /dev/video0` works well.  `mpv /dev/video1` fails with:

[ffmpeg/demuxer] video4linux2,v4l2: ioctl(VIDIOC_G_INPUT): Inappropriate ioctl for device

`v4l-info /dev/video1` shows:

### v4l2 device info [/dev/video1] ###
general info
    VIDIOC_QUERYCAP
	driver                  : "uvcvideo"
	card                    : "Integrated Camera: Integrated C"
	bus_info                : "usb-0000:00:1a.0-1.6"
	version                 : 5.8.7
	capabilities            : 0x84a00001 [VIDEO_CAPTURE,?,?,STREAMING,(null)]

standards

inputs

video capture
VIDIOC_G_FMT(VIDEO_CAPTURE): Invalid argument

controls

I don't understand the purpose of the second device (if any).  With
tracing enabled, there are references to "entity 1" and "entity 2" in
the kernel log.  Perhaps this is expected behavior?  If not, I would be
happy to help debug further.

Thanks for all of your efforts maintaining uvcvideo!

Best,
Kevin

[1]: https://www.ideasonboard.org/uvc/

Re: [linux-uvc-devel] [PATCH RESEND v3 0/5] media: uvcvideo: Fix race conditions

[Laurent P. <lau...@id...>]

Hi Guenter,

On Wed, Sep 16, 2020 at 07:25:42PM -0700, Guenter Roeck wrote:
> Something seems to have gone wrong with v3 of this patch series.
> I am sure I sent it out, but I don't find it anywhere.
> Resending. Sorry for any duplicates.

I haven't checked the mailing list, but I've found it in my inbox :-)
I'm not forgetting about you, just been fairly busy recently. I still
plan to try and provide an alternative implementation in the V4L2 core
(in a form that I think should even be moved to the cdev core) that
would fix this for all drivers.

By the way, as you managed to get hold of non-UVC webcams, one thing you
could try in your tests to make the drivers misbehave is to block on a
DQBUF call, and unplug the device at that time. When blocking, DQBUF
releases the driver lock (through the vb2ops .wait_prepare() and
.wait_finis() operations for drivers based on vb2), so this may allow
unregistration to proceed without waiting for userspace calls to
complete.

> The uvcvideo code has no lock protection against USB disconnects
> while video operations are ongoing. This has resulted in random
> error reports, typically pointing to a crash in usb_ifnum_to_if(),
> called from usb_hcd_alloc_bandwidth(). A typical traceback is as
> follows.
> 
> usb 1-4: USB disconnect, device number 3
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> PGD 0 P4D 0
> Oops: 0000 [#1] PREEMPT SMP PTI
> CPU: 0 PID: 5633 Comm: V4L2CaptureThre Not tainted 4.19.113-08536-g5d29ca36db06 #1
> Hardware name: GOOGLE Edgar, BIOS Google_Edgar.7287.167.156 03/25/2019
> RIP: 0010:usb_ifnum_to_if+0x29/0x40
> Code: <...>
> RSP: 0018:ffffa46f42a47a80 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff904a396c9000
> RDX: ffff904a39641320 RSI: 0000000000000001 RDI: 0000000000000000
> RBP: ffffa46f42a47a80 R08: 0000000000000002 R09: 0000000000000000
> R10: 0000000000009975 R11: 0000000000000009 R12: 0000000000000000
> R13: ffff904a396b3800 R14: ffff904a39e88000 R15: 0000000000000000
> FS: 00007f396448e700(0000) GS:ffff904a3ba00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 000000016cb46000 CR4: 00000000001006f0
> Call Trace:
>  usb_hcd_alloc_bandwidth+0x1ee/0x30f
>  usb_set_interface+0x1a3/0x2b7
>  uvc_video_start_transfer+0x29b/0x4b8 [uvcvideo]
>  uvc_video_start_streaming+0x91/0xdd [uvcvideo]
>  uvc_start_streaming+0x28/0x5d [uvcvideo]
>  vb2_start_streaming+0x61/0x143 [videobuf2_common]
>  vb2_core_streamon+0xf7/0x10f [videobuf2_common]
>  uvc_queue_streamon+0x2e/0x41 [uvcvideo]
>  uvc_ioctl_streamon+0x42/0x5c [uvcvideo]
>  __video_do_ioctl+0x33d/0x42a
>  video_usercopy+0x34e/0x5ff
>  ? video_ioctl2+0x16/0x16
>  v4l2_ioctl+0x46/0x53
>  do_vfs_ioctl+0x50a/0x76f
>  ksys_ioctl+0x58/0x83
>  __x64_sys_ioctl+0x1a/0x1e
>  do_syscall_64+0x54/0xde
> 
> While there are not many references to this problem on mailing lists, it is
> reported on a regular basis on various Chromebooks (roughly 300 reports
> per month). The problem is relatively easy to reproduce by adding msleep()
> calls into the code.
> 
> I tried to reproduce the problem with non-uvcvideo webcams, but was
> unsuccessful. I was unable to get Philips (pwc) webcams to work. gspca
> based webcams don't experience the problem, or at least I was unable to
> reproduce it (The gspa driver does not trigger sending USB messages in the
> open function, and otherwise uses the locking mechanism provided by the
> v4l2/vb2 core).
> 
> I don't presume to claim that I found every issue, but this patch series
> should fix at least the major problems.
> 
> The patch series was tested exensively on a Chromebook running chromeos-4.19
> and on a Linux system running a v5.8.y based kernel.
> 
> v3:
> - In patch 5/5, add missing calls to usb_autopm_put_interface() and kfree()
>   to failure code path
> 
> v2:
> - Added details about problem frequency and testing with non-uvc webcams
>   to summary
> - In patch 4/5, return EPOLLERR instead of -ENODEV on poll errors
> - Fix description in patch 5/5
> 
> ----------------------------------------------------------------
> Guenter Roeck (5):
>       media: uvcvideo: Cancel async worker earlier
>       media: uvcvideo: Lock video streams and queues while unregistering
>       media: uvcvideo: Release stream queue when unregistering video device
>       media: uvcvideo: Protect uvc queue file operations against disconnect
>       media: uvcvideo: Abort uvc_v4l2_open if video device is unregistered
> 
>  drivers/media/usb/uvc/uvc_ctrl.c   | 11 ++++++----
>  drivers/media/usb/uvc/uvc_driver.c | 12 ++++++++++
>  drivers/media/usb/uvc/uvc_queue.c  | 32 +++++++++++++++++++++++++--
>  drivers/media/usb/uvc/uvc_v4l2.c   | 45 ++++++++++++++++++++++++++++++++++++--
>  drivers/media/usb/uvc/uvcvideo.h   |  1 +
>  5 files changed, 93 insertions(+), 8 deletions(-)

-- 
Regards,

Laurent Pinchart

[linux-uvc-devel] Dino-lite microscope camera LED

[Gregoire G. <gre...@ge...>]

Hello,

I have a a Dino lite microscope camera (AM3113T). I'm trying to turn on 
the LED on my Linux PC running kernel 5.4.0-47.

On a side note, there is a button on that camera, why the f... the 
creators aren't using a press on that button to turn on/off the led? 
Seriously?!?

Anyway, I have read this 2017 thread: 
https://sourceforge.net/p/linux-uvc/mailman/message/35919971/

I have tried to write a c application to avoid any kernel hacking as 
explained here: 
https://stackoverflow.com/questions/63841431/libusb-error-when-doing-libusb-control-transfer

Any comment on that question would be useful.

Then, I have started to hack the uvc driver with the patch listed on the 
original thread.

Even after patching, I still get:

root@yoga:~# uvcdynctrl -S 4:3 8001f1
Assuming hex value (base 16)
query control size of : 3
query control flags of: 0x3
query minimum value of: (LE)0x000000  (BE)0x000000
query maximum value of: (LE)0xffffff  (BE)0xffffff
query default value of: (LE)0x000000  (BE)0x000000
query step size of    : (LE)0x010000  (BE)0x000001
ERROR: Unable to set the control value: A Video4Linux2 API call returned 
an unexpected error 32. (Code: 12)

root@yoga:~# dmesg -c
[ 5447.852527] usbcore: registered new interface driver uvcvideo
[ 5447.852528] USB Video Class driver (1.1.1)
[ 5455.096257] Fixing USB a168:0710 4/3 GET_LEN: 11 -> 3
[ 5455.098492] Fixing USB a168:0710 4/3 GET_LEN: 11 -> 3
[ 5455.104133] uvcvideo: Failed to query (SET_CUR) UVC control 3 on unit 
4: -32 (exp. 3).

The uvc kernel code has evolved a little bit since the 2017 thread. My 
kernel code looks like this:



static void uvc_fixup_query_ctrl_len(const struct uvc_device *dev, __u8 
unit,
        __u8 cs, void *data)
{
        struct uvc_ctrl_fixup {
                struct usb_device_id id;
                u8 unit;
                u8 selector;
                u16 len;
        };

        static const struct uvc_ctrl_fixup fixups[] = {
                 { { USB_DEVICE(0xa168, 0x0710) }, 4, 3, 3 },//Is this 4 
3 3??????
        };

        unsigned int i;

        for (i = 0; i < ARRAY_SIZE(fixups); ++i) {
                if (!usb_match_one_id(dev->intf, &fixups[i].id))
                        continue;

		///Let's force the hacking ?????????
                 //if (!(fixups[i].unit == unit && fixups[i].selector == 
cs))
                        //continue;

                printk(
                          "Fixing USB %04x:%04x %u/%u GET_LEN: %u -> %u",
                          fixups[i].id.idVendor, fixups[i].id.idProduct,
                          unit, cs,
                          le16_to_cpup((__le16 *)data), fixups[i].len);
                *((__le16 *)data) = cpu_to_le16(fixups[i].len);
                break;
        }
}



int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit,
			u8 intfnum, u8 cs, void *data, u16 size)
{
	int ret;
	u8 error;
	u8 tmp;


	ret = __uvc_query_ctrl(dev, query, unit, intfnum, cs, data, size,
				UVC_CTRL_CONTROL_TIMEOUT);

	if (query == UVC_GET_LEN && size == 2) {
		uvc_fixup_query_ctrl_len(dev, unit, cs, data);
		return 0;//Should I force returning sucess?????
}

	if (likely(ret == size))
		return 0;

	uvc_printk(KERN_ERR,
		   "Failed to query (%s) UVC control %u on unit %u: %d (exp. %u).\n",
		   uvc_query_name(query), cs, unit, ret, size);


Can anyone provide some help or direction to make this work? Many thanks 
in advance,

Grégoire

[linux-uvc-devel] Trying to get AVEO Cheetah3 USB2.0 Device to work

[Chris R. <la...@gm...>]

 When I plug it in, dmesg shows:

[  185.456597] usb 1-4: USB disconnect, device number 2
[  193.643879] usb 1-4: new high-speed USB device number 4 using xhci_hcd
[  193.680489] usb 1-4: New USB device found, idVendor=1871,
idProduct=01b0, bcdDevice= 0.05
[  193.680490] usb 1-4: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[  193.680491] usb 1-4: Product: AVEO Cheetah3 USB2.0 Device
[  193.680492] usb 1-4: Manufacturer: AVEO Technology Corp.


lsusb output for it:

Bus 001 Device 004: ID 1871:01b0 Aveo Technology Corp. AVEO Cheetah3 USB2.0
Device


I'm trying to see it using webcamoid software, but it doesn't see the
device at all.  I also tried guvcview but no luck there either.

I'm running under Gentoo Linux, custom 5.5.7 kernel build.

I'm trying to work out: is the device supported?  What should I look into
fixing if it is supported?  What kernel options should I use or need?  Any
libraries, etc that I should have installed?

Thanks for any help,

Chris

Re: [linux-uvc-devel] [PATCH 0/5] media: uvcvideo: Fix race conditions

[Laurent P. <lau...@id...>]

Hi Guenter,

On Sun, Aug 30, 2020 at 01:48:24PM -0700, Guenter Roeck wrote:
> On 8/30/20 8:58 AM, Laurent Pinchart wrote:
> > On Sun, Aug 30, 2020 at 08:04:38AM -0700, Guenter Roeck wrote:
> >> The uvcvideo code has no lock protection against USB disconnects
> >> while video operations are ongoing. This has resulted in random
> >> error reports, typically pointing to a crash in usb_ifnum_to_if(),
> >> called from usb_hcd_alloc_bandwidth(). A typical traceback is as
> >> follows.
> >>
> >> usb 1-4: USB disconnect, device number 3
> >> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> >> PGD 0 P4D 0
> >> Oops: 0000 [#1] PREEMPT SMP PTI
> >> CPU: 0 PID: 5633 Comm: V4L2CaptureThre Not tainted 4.19.113-08536-g5d29ca36db06 #1
> >> Hardware name: GOOGLE Edgar, BIOS Google_Edgar.7287.167.156 03/25/2019
> >> RIP: 0010:usb_ifnum_to_if+0x29/0x40
> >> Code: <...>
> >> RSP: 0018:ffffa46f42a47a80 EFLAGS: 00010246
> >> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff904a396c9000
> >> RDX: ffff904a39641320 RSI: 0000000000000001 RDI: 0000000000000000
> >> RBP: ffffa46f42a47a80 R08: 0000000000000002 R09: 0000000000000000
> >> R10: 0000000000009975 R11: 0000000000000009 R12: 0000000000000000
> >> R13: ffff904a396b3800 R14: ffff904a39e88000 R15: 0000000000000000
> >> FS: 00007f396448e700(0000) GS:ffff904a3ba00000(0000) knlGS:0000000000000000
> >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >> CR2: 0000000000000000 CR3: 000000016cb46000 CR4: 00000000001006f0
> >> Call Trace:
> >>  usb_hcd_alloc_bandwidth+0x1ee/0x30f
> >>  usb_set_interface+0x1a3/0x2b7
> >>  uvc_video_start_transfer+0x29b/0x4b8 [uvcvideo]
> >>  uvc_video_start_streaming+0x91/0xdd [uvcvideo]
> >>  uvc_start_streaming+0x28/0x5d [uvcvideo]
> >>  vb2_start_streaming+0x61/0x143 [videobuf2_common]
> >>  vb2_core_streamon+0xf7/0x10f [videobuf2_common]
> >>  uvc_queue_streamon+0x2e/0x41 [uvcvideo]
> >>  uvc_ioctl_streamon+0x42/0x5c [uvcvideo]
> >>  __video_do_ioctl+0x33d/0x42a
> >>  video_usercopy+0x34e/0x5ff
> >>  ? video_ioctl2+0x16/0x16
> >>  v4l2_ioctl+0x46/0x53
> >>  do_vfs_ioctl+0x50a/0x76f
> >>  ksys_ioctl+0x58/0x83
> >>  __x64_sys_ioctl+0x1a/0x1e
> >>  do_syscall_64+0x54/0xde
> >>
> >> While this is problem rarely observed in the field, it is relatively easy
> >> to reproduce by adding msleep() calls into the code.
> >>
> >> I don't presume to claim that I found every issue, but this patch series
> >> should fix at least the major problems.
> >>
> >> The patch series was tested exensively on a Chromebook running chromeos-4.19
> >> and on a Linux system running a v5.8.y based kernel.
> > 
> > I'll review each patch individually, but I think 2/5, 4/5 and 5/5 should
> > be handled in the V4L2 core, not the uvcvideo driver. Otherwise we would
> > have to replicate that logic in all drivers, while I think it can easily
> > be implemented in a generic fashion as previously discussed.
> > 
> The problem is that the v4l2 core already does support locking. There is
> a global lock, in struct video_device, a queue lock in struct v4l2_m2m_ctx,
> and another queue lock in struct vb2_queue. However, all of those have
> to be initialized from the driver. The uvcvideo driver uses its own locks and
> does not set the lock pointers in the various generic structures. I was able
> to figure out how to use the uvcvideo specific locks in the uvcvideo
> driver, but all my attempts to initialize and use the generic locks failed.
> 
> It may well be that the generic code isn't entirely clean - for example
> I am not sure if the lock protection in v4l2_open() is complete since
> it doesn't handle disconnects after checking if the video device is still
> registered (and I don't really see the point of the second video_is_registered()
> call in v4l2_open). However, that may just be a lack of understanding on my
> side on how the code is supposed to work. Maybe the actual device open function
> is expected to have its own protection against underlying hardware removal
> and video device unregistration while opening the device.
> 
> [ Regarding the second call to video_is_registered() in v4l2_open():
>   Add msleep(5000) between it and the call to the driver open function,
>   disconnect the device during the sleep, and it will happily call the device
>   open function on a non-registered video device. That is what patch 5/5 tries
>   to fix or the uvcvideo driver.
>   The same problem applies to other file operations in v4l2-dev.c: They all
>   check if the video device is registered before calling the device
>   specific code, but I don't really see the point of doing that because
>   there is no protection against unregistration after the check was made
>   and before/while the device specific code is running.
>   Patch 4/5 tries to fix this for the uvcvideo driver.
>   If that is a bug in the v4l2 code, I'll be happy to work on a fix,
>   but the only generic fix I could think of would be to utilize the lock in
>   struct video_device ... but that lock isn't initialized by the uvcvideo
>   driver.
> ]
> 
> Either case, I don't think my understanding of the interaction between
> v4l2 and uvcvideo is good enough to make more invasive changes. I _think_
> any generic improvement should start with refactoring the uvcvideo code to
> use the v4l2 locking mechanism. However, from the exchange here, my
> understanding is that this locking mechanism is not used on purpose. That
> means we'll have a uvcvideo specific locking mechanism, period, and I don't
> think it is even possible to solve the problem without utilizing this locking
> mechanism.
> 
> Of course, it may as well be that I am completely off track and clueless.
> After all, the first time I looked into this code was about two weeks ago.
> So please bear with me if I talk nonsense.

It would be rather impolite to claim you're clueless, given that you
managed to write this patch series only two weeks after first looking
into the problem :-)

I'll try to prototype what I envision would be a good solution in the
V4L2 core. If stars align, I may even try to push it one level up, to
the chardev layer. Would you then be able to test it ?

> >> ----------------------------------------------------------------
> >> Guenter Roeck (5):
> >>       media: uvcvideo: Cancel async worker earlier
> >>       media: uvcvideo: Lock video streams and queues while unregistering
> >>       media: uvcvideo: Release stream queue when unregistering video device
> >>       media: uvcvideo: Protect uvc queue file operations against disconnect
> >>       media: uvcvideo: In uvc_v4l2_open, check if video device is registered
> >>
> >>  drivers/media/usb/uvc/uvc_ctrl.c   | 11 ++++++----
> >>  drivers/media/usb/uvc/uvc_driver.c | 12 ++++++++++
> >>  drivers/media/usb/uvc/uvc_queue.c  | 32 +++++++++++++++++++++++++--
> >>  drivers/media/usb/uvc/uvc_v4l2.c   | 45 ++++++++++++++++++++++++++++++++++++--
> >>  drivers/media/usb/uvc/uvcvideo.h   |  1 +
> >>  5 files changed, 93 insertions(+), 8 deletions(-)

-- 
Regards,

Laurent Pinchart

Re: [linux-uvc-devel] [PATCH 0/5] media: uvcvideo: Fix race conditions

[Laurent P. <lau...@id...>]

Hi Guenter,

Thank you for the patches.

On Sun, Aug 30, 2020 at 08:04:38AM -0700, Guenter Roeck wrote:
> The uvcvideo code has no lock protection against USB disconnects
> while video operations are ongoing. This has resulted in random
> error reports, typically pointing to a crash in usb_ifnum_to_if(),
> called from usb_hcd_alloc_bandwidth(). A typical traceback is as
> follows.
> 
> usb 1-4: USB disconnect, device number 3
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> PGD 0 P4D 0
> Oops: 0000 [#1] PREEMPT SMP PTI
> CPU: 0 PID: 5633 Comm: V4L2CaptureThre Not tainted 4.19.113-08536-g5d29ca36db06 #1
> Hardware name: GOOGLE Edgar, BIOS Google_Edgar.7287.167.156 03/25/2019
> RIP: 0010:usb_ifnum_to_if+0x29/0x40
> Code: <...>
> RSP: 0018:ffffa46f42a47a80 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff904a396c9000
> RDX: ffff904a39641320 RSI: 0000000000000001 RDI: 0000000000000000
> RBP: ffffa46f42a47a80 R08: 0000000000000002 R09: 0000000000000000
> R10: 0000000000009975 R11: 0000000000000009 R12: 0000000000000000
> R13: ffff904a396b3800 R14: ffff904a39e88000 R15: 0000000000000000
> FS: 00007f396448e700(0000) GS:ffff904a3ba00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 000000016cb46000 CR4: 00000000001006f0
> Call Trace:
>  usb_hcd_alloc_bandwidth+0x1ee/0x30f
>  usb_set_interface+0x1a3/0x2b7
>  uvc_video_start_transfer+0x29b/0x4b8 [uvcvideo]
>  uvc_video_start_streaming+0x91/0xdd [uvcvideo]
>  uvc_start_streaming+0x28/0x5d [uvcvideo]
>  vb2_start_streaming+0x61/0x143 [videobuf2_common]
>  vb2_core_streamon+0xf7/0x10f [videobuf2_common]
>  uvc_queue_streamon+0x2e/0x41 [uvcvideo]
>  uvc_ioctl_streamon+0x42/0x5c [uvcvideo]
>  __video_do_ioctl+0x33d/0x42a
>  video_usercopy+0x34e/0x5ff
>  ? video_ioctl2+0x16/0x16
>  v4l2_ioctl+0x46/0x53
>  do_vfs_ioctl+0x50a/0x76f
>  ksys_ioctl+0x58/0x83
>  __x64_sys_ioctl+0x1a/0x1e
>  do_syscall_64+0x54/0xde
> 
> While this is problem rarely observed in the field, it is relatively easy
> to reproduce by adding msleep() calls into the code.
> 
> I don't presume to claim that I found every issue, but this patch series
> should fix at least the major problems.
> 
> The patch series was tested exensively on a Chromebook running chromeos-4.19
> and on a Linux system running a v5.8.y based kernel.

I'll review each patch individually, but I think 2/5, 4/5 and 5/5 should
be handled in the V4L2 core, not the uvcvideo driver. Otherwise we would
have to replicate that logic in all drivers, while I think it can easily
be implemented in a generic fashion as previously discussed.

> ----------------------------------------------------------------
> Guenter Roeck (5):
>       media: uvcvideo: Cancel async worker earlier
>       media: uvcvideo: Lock video streams and queues while unregistering
>       media: uvcvideo: Release stream queue when unregistering video device
>       media: uvcvideo: Protect uvc queue file operations against disconnect
>       media: uvcvideo: In uvc_v4l2_open, check if video device is registered
> 
>  drivers/media/usb/uvc/uvc_ctrl.c   | 11 ++++++----
>  drivers/media/usb/uvc/uvc_driver.c | 12 ++++++++++
>  drivers/media/usb/uvc/uvc_queue.c  | 32 +++++++++++++++++++++++++--
>  drivers/media/usb/uvc/uvc_v4l2.c   | 45 ++++++++++++++++++++++++++++++++++++--
>  drivers/media/usb/uvc/uvcvideo.h   |  1 +
>  5 files changed, 93 insertions(+), 8 deletions(-)

-- 
Regards,

Laurent Pinchart

[linux-uvc-devel] Webcam black screen feed (04f2:b5c5)

[Jose A. S. <sau...@gm...>]

Hello members of the group,

I have a problem with the integraged webcam on my Acer SF114-32 laptop.

When I open the webcam with any app (skype, qv4l2,etc) , I get a black screen.  It seems like the camera is recognized and the connection is made because  the green light on the camera module turns on at that moment, however no image.

I thought it was a hardware problem so I bought another camera module and I get the same result with the new module. This made me write to this group for help.

I am pretty certain I have tested the camera with linux when I bought it (and worked) but it has been a while and now I doubt the test might have been under Windows.

uname -a
Linux enzo 5.8.5_1 #1 SMP Thu Aug 27 08:23:40 UTC 2020 x86_64 GNU/Linux

I am attaching log files.

Thanks in advance for any help.

Regards, Jose

Re: [linux-uvc-devel] Webcam on linux mint

[Jack <ost...@us...>]

Michael,

Welcome to Linux.

On 2020.08.26 10:03, Michael Issott wrote:
> I have a Microsoft LifeCam vx2000 webcam
> I've just moved from windows vista (yes I know) to Linux mint 20
> How can I get this webcam to work on the Linux system please
> I know little about Linux as yet but am learning slowly , so please  
> be gentle with me and don't talk above my head
> I'm 73 but not quite a Luddite
> Thanks
To get help,  you need to provide a bit more information.  If you have  
tracked your way to this list, I'll assume you have actually tried to  
use the camera and not succeeded.  In that case, you need to tell us  
what you have tried and what errors you have gotten.  Other useful  
information would be the output of running lsusb from a command prompt  
(Konsole or xterm, for example, depending on your Desktop  
Environment.)  What program have you tried to use the camera with?  Are  
there any errors or just that it says it can't find any camera.  It  
would also help if you could post what dmesg says right after plugging  
in the camera (defer that for now if you don't know what it is or how  
to get it.)  (In all cases, it's good for you to confirm or deny any  
assumptions we make, and to let us know if we do request something you  
don't know how to do.)

Jack (only 66)

[linux-uvc-devel] Webcam on linux mint

[Michael I. <mi...@gm...>]

I have a Microsoft LifeCam vx2000 webcam
I've just moved from windows vista (yes I know) to Linux mint 20
How can I get this webcam to work on the Linux system please
I know little about Linux as yet but am learning slowly , so please be gentle with me and don't talk above my head
I'm 73 but not quite a Luddite 
Thanks

[linux-uvc-devel] Sunplus Webcam 1bcf:248c (not supported) Failed to query UVC (1.10) probe control

[Coba <co...@co...>]

Hello,

I'm struggling to get to work a SunplusIT USB webcam. All other video 
devices work as expected. The camera is recognized but can't be loaded 
by the uvcvideo module. No video device is created. The integrated 
microphone of the device works fine.

The relevant dmesg output is:

usb 1-2: New USB device found, idVendor=1bcf, idProduct=248c, bcdDevice= 
4.17
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 

usb 1-2: Product: USB Camera 

usb 1-2: Manufacturer: SunplusIT Inc 

usb 1-2: SerialNumber: 01.00.00 

uvcvideo: Found UVC 1.10 device USB Camera (1bcf:248c) 

uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling 
workaround.
uvcvideo: Failed to query (129) UVC probe control : 26 (exp. 34). 

uvcvideo: Failed to initialize the device (-5). 

usb 1-2: 3:1: cannot get freq at ep 0x86 

usb 1-2: 3:2: cannot set freq 11025 to ep 0x86 

usb 1-2: 3:3: cannot set freq 16000 to ep 0x86 

usb 1-2: 3:4: cannot get freq at ep 0x86 

usb 1-2: 3:5: cannot set freq 24000 to ep 0x86 

usb 1-2: 3:6: cannot set freq 32000 to ep 0x86 

usb 1-2: 3:7: cannot get freq at ep 0x86 

usb 1-2: 3:8: cannot set freq 48000 to ep 0x86 

usb 1-2: Warning! Unlikely big volume range (=4096), cval->res is 
probably wrong.
usb 1-2: [7] FU [Mic Capture Volume] ch = 1, val = 0/4096/1 


I've tried enabling all quirks module options except 0x8 and 0x20, but 
the problem persists. I'm attaching to this email a dmesg log without 
enabling any quirk, dmesg logs with quirks 0x2 and 0x100 and a lsusb dump.

Using the Zen kernel 5.8.3 in archlinux. As far as I know it doesn't 
modify any video devices related code.

Thanks in advance for any support.

Warm regards,

Coba.

Re: [linux-uvc-devel] Protecting uvcvideo againt USB device disconnect [Was: Re: Protecting usb_set_interface() against device removal]

[Laurent P. <lau...@id...>]

Hi Guenter,

On Wed, Aug 19, 2020 at 04:08:51PM -0700, Guenter Roeck wrote:
> On Wed, Aug 19, 2020 at 04:30:02AM +0300, Laurent Pinchart wrote:
> > On Mon, Aug 17, 2020 at 01:00:49PM +0200, Hans Verkuil wrote:
> > > On 17/08/2020 01:51, Laurent Pinchart wrote:
> > > > On Sun, Aug 16, 2020 at 08:54:18AM -0700, Guenter Roeck wrote:
> > > >> On 8/16/20 5:18 AM, Laurent Pinchart wrote:
> > > >>> CC'ing Hans Verkuil and Sakari Ailus for the discussion about handling
> > > >>> file operations and disconnect in V4L2.
> > > >>>
> > > >>> On Sat, Aug 15, 2020 at 05:33:15PM -0700, Guenter Roeck wrote:
> > > >>>> + lin...@li...
> > > >>>> + lin...@vg...
> > > >>>> + lau...@id...
> > > >>>>
> > > >>>> and changed subject
> > > >>>>
> > > >>>> On Fri, Aug 14, 2020 at 10:07:39PM -0400, Alan Stern wrote:
> > > >>>>> On Fri, Aug 14, 2020 at 04:07:03PM -0700, Guenter Roeck wrote:
> > > >>>>>> Hi all,
> > > >>>>>>
> > > >>>>>> over time, there have been a number of reports of crashes in usb_ifnum_to_if(),
> > > >>>>>> called from usb_hcd_alloc_bandwidth, which is in turn called from usb_set_interface().
> > > >>>>>> Examples are [1] [2] [3]. A typical backtrace is:
> > > >>>>>>
> > > >>>>>> <3>[ 3489.445468] intel_sst_acpi 808622A8:00: sst: Busy wait failed, cant send this msg
> > > >>>>>> <6>[ 3490.507273] usb 1-4: USB disconnect, device number 3
> > > >>>>>> <1>[ 3490.516670] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> > > >>>>>> <6>[ 3490.516680] PGD 0 P4D 0
> > > >>>>>> <4>[ 3490.516687] Oops: 0000 [#1] PREEMPT SMP PTI
> > > >>>>>> <4>[ 3490.516693] CPU: 0 PID: 5633 Comm: V4L2CaptureThre Not tainted 4.19.113-08536-g5d29ca36db06 #1
> > > >>>>>> <4>[ 3490.516696] Hardware name: GOOGLE Edgar, BIOS Google_Edgar.7287.167.156 03/25/2019
> > > >>>>>> <4>[ 3490.516706] RIP: 0010:usb_ifnum_to_if+0x29/0x40
> > > >>>>>> <4>[ 3490.516710] Code: ee 0f 1f 44 00 00 55 48 89 e5 48 8b 8f f8 03 00 00 48 85 c9 74 27 44 0f b6 41 04 4d 85 c0 74 1d 31 ff 48 8b 84 f9 98 00 00 00 <48> 8b 10 0f b6 52 02 39 f2 74 0a 48 ff c7 4c 39 c7 72 e5 31 c0 5d
> > > >>>>>> <4>[ 3490.516714] RSP: 0018:ffffa46f42a47a80 EFLAGS: 00010246
> > > >>>>>> <4>[ 3490.516718] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff904a396c9000
> > > >>>>>> <4>[ 3490.516721] RDX: ffff904a39641320 RSI: 0000000000000001 RDI: 0000000000000000
> > > >>>>>> <4>[ 3490.516724] RBP: ffffa46f42a47a80 R08: 0000000000000002 R09: 0000000000000000
> > > >>>>>> <4>[ 3490.516727] R10: 0000000000009975 R11: 0000000000000009 R12: 0000000000000000
> > > >>>>>> <4>[ 3490.516731] R13: ffff904a396b3800 R14: ffff904a39e88000 R15: 0000000000000000
> > > >>>>>> <4>[ 3490.516735] FS: 00007f396448e700(0000) GS:ffff904a3ba00000(0000) knlGS:0000000000000000
> > > >>>>>> <4>[ 3490.516738] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > >>>>>> <4>[ 3490.516742] CR2: 0000000000000000 CR3: 000000016cb46000 CR4: 00000000001006f0
> > > >>>>>> <4>[ 3490.516745] Call Trace:
> > > >>>>>> <4>[ 3490.516756] usb_hcd_alloc_bandwidth+0x1ee/0x30f
> > > >>>>>> <4>[ 3490.516762] usb_set_interface+0x1a3/0x2b7
> > > >>>>>> <4>[ 3490.516773] uvc_video_start_transfer+0x29b/0x4b8 [uvcvideo]
> > > >>>>>> <4>[ 3490.516781] uvc_video_start_streaming+0x91/0xdd [uvcvideo]
> > > >>>>>> <4>[ 3490.516787] uvc_start_streaming+0x28/0x5d [uvcvideo]
> > > >>>>>> <4>[ 3490.516795] vb2_start_streaming+0x61/0x143 [videobuf2_common]
> > > >>>>>> <4>[ 3490.516801] vb2_core_streamon+0xf7/0x10f [videobuf2_common]
> > > >>>>>> <4>[ 3490.516807] uvc_queue_streamon+0x2e/0x41 [uvcvideo]
> > > >>>>>> <4>[ 3490.516814] uvc_ioctl_streamon+0x42/0x5c [uvcvideo]
> > > >>>>>> <4>[ 3490.516820] __video_do_ioctl+0x33d/0x42a
> > > >>>>>> <4>[ 3490.516826] video_usercopy+0x34e/0x5ff
> > > >>>>>> <4>[ 3490.516831] ? video_ioctl2+0x16/0x16
> > > >>>>>> <4>[ 3490.516837] v4l2_ioctl+0x46/0x53
> > > >>>>>> <4>[ 3490.516843] do_vfs_ioctl+0x50a/0x76f
> > > >>>>>> <4>[ 3490.516848] ksys_ioctl+0x58/0x83
> > > >>>>>> <4>[ 3490.516853] __x64_sys_ioctl+0x1a/0x1e
> > > >>>>>> <4>[ 3490.516858] do_syscall_64+0x54/0xde
> > > >>>>>>
> > > >>>>>> I have been able to reproduce the problem on a Chromebook by strategically placing
> > > >>>>>> msleep() calls into usb_set_interface() and usb_disable_device(). Ultimately, the
> > > >>>>>> problem boils down to lack of protection against device removal in usb_set_interface()
> > > >>>>>> [and/or possibly other callers of usb_ifnum_to_if()].
> > > >>>>>>
> > > >>>>>> Sequence of events is roughly as follows:
> > > >>>>>>
> > > >>>>>> - usb_set_interface() is called and proceeds to some point, possibly to
> > > >>>>>>   mutex_lock(hcd->bandwidth_mutex);
> > > >>>>>> - Device removal event is detected, and usb_disable_device() is called
> > > >>>>>
> > > >>>>> At this point all interface drivers get unbound (their disconnect 
> > > >>>>> routines are called).
> > > >>>>>
> > > >>>>>> - usb_disable_device() starts removing actconfig data. It has removed
> > > >>>>>>   and cleared dev->actconfig->interface[i], but not dev->actconfig
> > > >>>>>> - usb_set_interface() calls usb_hcd_alloc_bandwidth(), which calls
> > > >>>>>>   usb_ifnum_to_if()
> > > >>>>>> - In usb_ifnum_to_if(), dev->actconfig is not NULL, but
> > > >>>>>>   dev->actconfig->interface[i] is NULL
> > > >>>>>> - crash
> > > >>>>>>
> > > >>>>>> Question is what we can do about this. Checking if dev->state != USB_STATE_NOTATTACHED
> > > >>>>>> in usb_ifnum_to_if() might be a possible approach, but strictly speaking it would
> > > >>>>>> still be racy since there is still no lock against device removal. I have not tried
> > > >>>>>> calling usb_lock_device() in usb_set_interface() - would that possibly be an option ?
> > > >>>>>
> > > >>>>> As far as I know, protecting against these races is the responsibility 
> > > >>>>> of the USB interface drivers.  They must make sure that their disconnect 
> > > >>>>> routines block until all outstanding calls to usb_set_interface return 
> > > >>>>> (in fact, until all outstanding device accesses have finished).
> > > >>>>>
> > > >>>>> For instance, in the log extract you showed, it's obvious that the 
> > > >>>>> uvc_start_streaming routine was running after the disconnect routine had 
> > > >>>>> returned, which looks like a bug in itself: Once the disconnect routine 
> > > >>>>> returns, the driver is not supposed to try to access the device at all 
> > > >>>>> because some other driver may now be bound to it.
> > > >>>>>
> > > >>>>> We can't just call usb_lock_device from within usb_set_interface, 
> > > >>>>> because usb_set_interface is often called with that lock already held.
> > > >>>>>
> > > >>>> I had a closer look into the uvcvideo driver and compared it to other usb
> > > >>>> drivers, including drivers in drivers/media/usb/ which connect to the video
> > > >>>> subsystem.
> > > >>>>
> > > >>>> The usbvideo driver lacks protection against calls to uvc_disconnect() while
> > > >>>
> > > >>> Are you confusing usbvideo and uvcvideo ? Both exist, and uvcvideo would
> > > >>> have been called usbvideo if the former hadn't already been in use.
> > > >>
> > > >> Yes, sorry :-(. I am not sure how s/uvc/usb/ happened.
> > > > 
> > > > No worries.
> > > > 
> > > >>>> calls into file operations are ongoing. This is pretty widespread, and not
> > > >>>> even limited to file operations (for example, there is a worker which is only
> > > >>>> canceled in uvc_delete, not in ucv_disconnect). The existing protection only
> > > >>>> ensures that no file operations are started after the call to ucv_disconnect,
> > > >>>> but that is insufficient.
> > > >>>>
> > > >>>> Other drivers do have that protection and make sure that no usb operations
> > > >>>> can happen after the disconnect call.
> > > >>>>
> > > >>>> The only remedy I can see is to rework the usbvideo driver and add the
> > > >>>> necessary protections. At first glance, it looks like this may be a
> > > >>>> substantial amount of work. I'd sign up for that, but before I start,
> > > >>>> I would like to get input from the usbvideo community. Is such an effort
> > > >>>> already going on ? If yes, how can I help ? If not, is the problem
> > > >>>> understood and accepted ? Are there any ideas on how to solve it ?
> > > >>>
> > > >>> This is something that has been discussed before, and needs to be solved
> > > >>> in the V4L2 framework itself, not in individual drivers. Not only would
> > > >>> this avoid rolling out the same code manually everywhere (in different
> > > >>> incorrect ways, as races are difficult to solve and implementations are
> > > >>> more often wrong than right), but it will also avoid similar issues for
> > > >>> non-USB devices.
> > > >>
> > > >> You mean code that ensures that no user-space v4l2 operation is in progress
> > > >> after video_device_unregister / v4l2_device_unregister return ? I agree,
> > > >> that would simplify the necessary changes on the uvc side.
> > > > 
> > > > I was thinking about adding a new function to be called from the
> > > > disconnect handler to implement the wait on end of userspace access, but
> > > > video_device_unregister() seems an even better idea.
> > > > v4l2_device_unregister() is probably not very useful as v4l2_device
> > > > isn't exposed to userspace, only video_device is (and v4l2_subdev and
> > > > media_device, but that's a different story, although probably still an
> > > > issue for the latter in the UVC driver).
> > > 
> > > Actually, all that is needed is to take the ioctl serialization lock in the disconnect
> > > function.
> > 
> > It's not just ioctls though, the other file operations also need to be
> > handled (read, write, mmap).
> > 
> > > See last paragraph in 1.4.1 here:
> > > 
> > > https://hverkuil.home.xs4all.nl/spec/driver-api/v4l2-dev.html
> > > 
> > > Since uvc uses its own lock, you need to take that one.
> > 
> > Drivers that use their own lock do so to avoid serializing all ioctls.
> > This means that different ioctls may be covered by different locks
> > (possibly with part of some ioctls running without locking). I don't
> > think we can just dismiss the issue saying those drivers need to
> > implement the disconnection manually. It would be much better to
> > integrate handling of userspace access with video_device_unregister()
> > like proposed above, as that will work for all drivers in a transparent
> > way. It would also be fairly simple to implement in the V4L2 core.
> 
> I don't think it is going to be that simple. Here is a traceback I was able
> to collect after playing with msleep() in various locations. This is
> _after_ uvc_disconnect() has returned, but before usb_disable_device()
> set dev->actconfig to NULL.
> 
> [ 9619.003726] config->interface[0] is NULL
> [ 9619.009114] WARNING: CPU: 0 PID: 2757 at drivers/usb/core/usb.c:285 usb_ifnum_to_if+0x81/0x85
>                ^^^ added log message and WARN() to prevent crash
> 
> [ 9619.018647] Modules linked in: snd_seq_dummy snd_seq bridge stp llc veth tun nf_nat_tftp nf_conntrack_tftp nf_nat_ftp nf_conntrack_ftp xfrm6_mode_tunnel xfrm6_mode_transport xfrm4_mode_tunnel xfrm4_mode_transport esp6 ah6 ip6t_REJECT ip6t_ipv6header wacom rfcomm cmac algif_hash algif_skcipher af_alg uinput snd_soc_sst_bxt_da7219_max98357a snd_soc_hdac_hdmi snd_soc_dmic snd_soc_skl_ssp_clk snd_soc_skl snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_acpi_intel_match snd_soc_acpi snd_hda_ext_core snd_intel_nhlt snd_hda_core snd_soc_max98357a acpi_als kfifo_buf industrialio snd_soc_da7219 ipt_MASQUERADE fuse snd_usb_audio snd_usbmidi_lib snd_hwdep snd_rawmidi snd_seq_device uvcvideo videobuf2_v4l2 videobuf2_common videobuf2_vmalloc videobuf2_memops iwlmvm iwl7000_mac80211 lzo_rle lzo_compress
> [ 9619.097545]  zram r8152 mii iwlwifi cfg80211 btusb btrtl btintel btbcm bluetooth ecdh_generic joydev
> [ 9619.107762] CPU: 0 PID: 2757 Comm: inotify_reader Not tainted 4.19.139 #20
> [ 9619.115443] Hardware name: Google Phaser/Phaser, BIOS Google_Phaser.10952.0.0 08/09/2018
> [ 9619.124490] RIP: 0010:usb_ifnum_to_if+0x81/0x85
> [ 9619.129542] Code: 02 44 39 f1 74 0a 48 ff c6 48 39 c6 72 df 31 db 48 89 d8 5b 41 5e 41 5f 5d c3 31 db 48 c7 c7 08 f8 cd a8 31 c0 e8 dd 1b 9f ff <0f> 0b eb e2 0f 1f 44 00 00 55 48 89 e5 44 8b 47 10 31 c0 45 85 c0
> [ 9619.150530] RSP: 0018:ffff9ee20141fa58 EFLAGS: 00010246
> [ 9619.156368] RAX: 438a0e5a525f1800 RBX: 0000000000000000 RCX: 0000000000000000
> [ 9619.164339] RDX: ffff975477a1de90 RSI: ffff975477a153d0 RDI: ffff975477a153d0
> [ 9619.172309] RBP: ffff9ee20141fa70 R08: 000000000000002c R09: 002daec189138d78
> [ 9619.180279] R10: 0000001000000000 R11: ffffffffa7da42e6 R12: ffff975459594800
> [ 9619.188241] R13: 0000000000000001 R14: 0000000000000001 R15: ffff975465376400
> [ 9619.196212] FS:  00007ddebffd6700(0000) GS:ffff975477a00000(0000) knlGS:0000000000000000
> [ 9619.205251] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 9619.211670] CR2: 0000000012c83000 CR3: 00000001bbaf8000 CR4: 0000000000340ef0
> [ 9619.219641] Call Trace:
> [ 9619.222378]  usb_set_interface+0x3b/0x2f3
> [ 9619.226862]  uvc_video_stop_streaming+0x38/0x81 [uvcvideo]
> [ 9619.232983]  uvc_stop_streaming+0x21/0x49 [uvcvideo]
> [ 9619.238531]  __vb2_queue_cancel+0x33/0x249 [videobuf2_common]
> [ 9619.244951]  vb2_core_queue_release+0x1c/0x45 [videobuf2_common]
> [ 9619.251662]  uvc_queue_release+0x26/0x32 [uvcvideo]
> [ 9619.257114]  uvc_v4l2_release+0x41/0xdd [uvcvideo]
> [ 9619.262469]  v4l2_release+0x99/0xed
> [ 9619.266367]  __fput+0xf0/0x1ea
> [ 9619.269778]  task_work_run+0x7f/0xa7
> [ 9619.273769]  do_exit+0x1d1/0x6eb
> [ 9619.277375]  do_group_exit+0x9d/0xac
> [ 9619.281367]  get_signal+0x135/0x482
> [ 9619.285262]  do_signal+0x4a/0x63c
> [ 9619.288965]  exit_to_usermode_loop+0x86/0xa5
> [ 9619.293732]  do_syscall_64+0x171/0x269
> [ 9619.297919]  ? __do_page_fault+0x272/0x474
> [ 9619.302495]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 9619.308156] RIP: 0033:0x7ddec156dc26
> [ 9619.312161] Code: Bad RIP value.
> [ 9619.315763] RSP: 002b:00007ddebffd5c10 EFLAGS: 00000293 ORIG_RAX: 0000000000000017
> [ 9619.324221] RAX: fffffffffffffdfe RBX: 000000000000000a RCX: 00007ddec156dc26
> [ 9619.332194] RDX: 0000000000000000 RSI: 00007ddebffd5d28 RDI: 000000000000000a
> [ 9619.340166] RBP: 00007ddebffd5c50 R08: 0000000000000000 R09: 0000000000000000
> [ 9619.348156] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ddebffd5d28
> [ 9619.356127] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> 
> usb_set_interface() should not be called anymore after uvc_disconnect(),
> or at east I think so (is that documented anywhere ?).
> Yet, that obviously happens, and it happens completely outside lock
> control. And this is just one instance where I was actually able
> to see the problem. I am quite sure that there are more.

Let's hope there are not too many :-) As you can see from the stack
trace, this happens at .release() (a.k.a. last close()) time. This code
path is the only one that the V4L2 core can't protect fully for drivers.
The good news is that there's thus only one code path that drivers would
need to handle manually.

I think we could fix this one by calling uvc_queue_release() in
uvc_disconnect(), after unregistering the video devices. The
uvc_queue_release() call in the .release() path would then become a
no-op, as everything will be stopped already.

> > > > We also have a v4l2_device_disconnect() function which is supposed to
> > > > handle hot-pluggable device disconnection, but it's fairly useless (I'd
> > > > even say harmful as it gives the illusion that hotplugging is correctly
> > > > handled, while in reality the media subsystem is plagged by hot-unplug
> > > > issues :-S).
> > > 
> > > The v4l2_device_disconnect() is there to remove a v4l2_dev reference to
> > > the device that is about to be removed when the disconnect() exists.
> > > Otherwise v4l2_dev->dev would point to a missing device.
> > > 
> > > However, I wonder if it is still needed: commit 236c5441d703 from 2011 added
> > > code to take a reference to v4l2_dev->dev in v4l2_device_register(). This
> > > should prevent the device from disappearing until v4l2_device_unregister() is
> > > called. I suspect that v4l2_device_disconnect() can be removed completely, and
> > > instead v4l2_device_unregister() just calls put_device(v4l2_dev->dev).
> > > 
> > > I don't like v4l2_device_disconnect() either, so if this works, then that would
> > > be a nice simplification.
> 
> Maybe I am missing something, but v4l2_device_unregister() already calls
> v4l2_device_disconnect(). With that, I don't see a difference to just calling
> v4l2_device_unregister().
> 
> Anyway, I'll keep digging.

-- 
Regards,

Laurent Pinchart

Re: [linux-uvc-devel] Protecting uvcvideo againt USB device disconnect [Was: Re: Protecting usb_set_interface() against device removal]

[Laurent P. <lau...@id...>]

Hi Hans,

On Wed, Aug 19, 2020 at 09:27:05AM +0200, Hans Verkuil wrote:
> On 19/08/2020 03:30, Laurent Pinchart wrote:
> > On Mon, Aug 17, 2020 at 01:00:49PM +0200, Hans Verkuil wrote:
> >> On 17/08/2020 01:51, Laurent Pinchart wrote:
> >>> On Sun, Aug 16, 2020 at 08:54:18AM -0700, Guenter Roeck wrote:
> >>>> On 8/16/20 5:18 AM, Laurent Pinchart wrote:
> >>>>> CC'ing Hans Verkuil and Sakari Ailus for the discussion about handling
> >>>>> file operations and disconnect in V4L2.
> >>>>>
> >>>>> On Sat, Aug 15, 2020 at 05:33:15PM -0700, Guenter Roeck wrote:
> >>>>>> + lin...@li...
> >>>>>> + lin...@vg...
> >>>>>> + lau...@id...
> >>>>>>
> >>>>>> and changed subject
> >>>>>>
> >>>>>> On Fri, Aug 14, 2020 at 10:07:39PM -0400, Alan Stern wrote:
> >>>>>>> On Fri, Aug 14, 2020 at 04:07:03PM -0700, Guenter Roeck wrote:
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>> over time, there have been a number of reports of crashes in usb_ifnum_to_if(),
> >>>>>>>> called from usb_hcd_alloc_bandwidth, which is in turn called from usb_set_interface().
> >>>>>>>> Examples are [1] [2] [3]. A typical backtrace is:
> >>>>>>>>
> >>>>>>>> <3>[ 3489.445468] intel_sst_acpi 808622A8:00: sst: Busy wait failed, cant send this msg
> >>>>>>>> <6>[ 3490.507273] usb 1-4: USB disconnect, device number 3
> >>>>>>>> <1>[ 3490.516670] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> >>>>>>>> <6>[ 3490.516680] PGD 0 P4D 0
> >>>>>>>> <4>[ 3490.516687] Oops: 0000 [#1] PREEMPT SMP PTI
> >>>>>>>> <4>[ 3490.516693] CPU: 0 PID: 5633 Comm: V4L2CaptureThre Not tainted 4.19.113-08536-g5d29ca36db06 #1
> >>>>>>>> <4>[ 3490.516696] Hardware name: GOOGLE Edgar, BIOS Google_Edgar.7287.167.156 03/25/2019
> >>>>>>>> <4>[ 3490.516706] RIP: 0010:usb_ifnum_to_if+0x29/0x40
> >>>>>>>> <4>[ 3490.516710] Code: ee 0f 1f 44 00 00 55 48 89 e5 48 8b 8f f8 03 00 00 48 85 c9 74 27 44 0f b6 41 04 4d 85 c0 74 1d 31 ff 48 8b 84 f9 98 00 00 00 <48> 8b 10 0f b6 52 02 39 f2 74 0a 48 ff c7 4c 39 c7 72 e5 31 c0 5d
> >>>>>>>> <4>[ 3490.516714] RSP: 0018:ffffa46f42a47a80 EFLAGS: 00010246
> >>>>>>>> <4>[ 3490.516718] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff904a396c9000
> >>>>>>>> <4>[ 3490.516721] RDX: ffff904a39641320 RSI: 0000000000000001 RDI: 0000000000000000
> >>>>>>>> <4>[ 3490.516724] RBP: ffffa46f42a47a80 R08: 0000000000000002 R09: 0000000000000000
> >>>>>>>> <4>[ 3490.516727] R10: 0000000000009975 R11: 0000000000000009 R12: 0000000000000000
> >>>>>>>> <4>[ 3490.516731] R13: ffff904a396b3800 R14: ffff904a39e88000 R15: 0000000000000000
> >>>>>>>> <4>[ 3490.516735] FS: 00007f396448e700(0000) GS:ffff904a3ba00000(0000) knlGS:0000000000000000
> >>>>>>>> <4>[ 3490.516738] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >>>>>>>> <4>[ 3490.516742] CR2: 0000000000000000 CR3: 000000016cb46000 CR4: 00000000001006f0
> >>>>>>>> <4>[ 3490.516745] Call Trace:
> >>>>>>>> <4>[ 3490.516756] usb_hcd_alloc_bandwidth+0x1ee/0x30f
> >>>>>>>> <4>[ 3490.516762] usb_set_interface+0x1a3/0x2b7
> >>>>>>>> <4>[ 3490.516773] uvc_video_start_transfer+0x29b/0x4b8 [uvcvideo]
> >>>>>>>> <4>[ 3490.516781] uvc_video_start_streaming+0x91/0xdd [uvcvideo]
> >>>>>>>> <4>[ 3490.516787] uvc_start_streaming+0x28/0x5d [uvcvideo]
> >>>>>>>> <4>[ 3490.516795] vb2_start_streaming+0x61/0x143 [videobuf2_common]
> >>>>>>>> <4>[ 3490.516801] vb2_core_streamon+0xf7/0x10f [videobuf2_common]
> >>>>>>>> <4>[ 3490.516807] uvc_queue_streamon+0x2e/0x41 [uvcvideo]
> >>>>>>>> <4>[ 3490.516814] uvc_ioctl_streamon+0x42/0x5c [uvcvideo]
> >>>>>>>> <4>[ 3490.516820] __video_do_ioctl+0x33d/0x42a
> >>>>>>>> <4>[ 3490.516826] video_usercopy+0x34e/0x5ff
> >>>>>>>> <4>[ 3490.516831] ? video_ioctl2+0x16/0x16
> >>>>>>>> <4>[ 3490.516837] v4l2_ioctl+0x46/0x53
> >>>>>>>> <4>[ 3490.516843] do_vfs_ioctl+0x50a/0x76f
> >>>>>>>> <4>[ 3490.516848] ksys_ioctl+0x58/0x83
> >>>>>>>> <4>[ 3490.516853] __x64_sys_ioctl+0x1a/0x1e
> >>>>>>>> <4>[ 3490.516858] do_syscall_64+0x54/0xde
> >>>>>>>>
> >>>>>>>> I have been able to reproduce the problem on a Chromebook by strategically placing
> >>>>>>>> msleep() calls into usb_set_interface() and usb_disable_device(). Ultimately, the
> >>>>>>>> problem boils down to lack of protection against device removal in usb_set_interface()
> >>>>>>>> [and/or possibly other callers of usb_ifnum_to_if()].
> >>>>>>>>
> >>>>>>>> Sequence of events is roughly as follows:
> >>>>>>>>
> >>>>>>>> - usb_set_interface() is called and proceeds to some point, possibly to
> >>>>>>>>   mutex_lock(hcd->bandwidth_mutex);
> >>>>>>>> - Device removal event is detected, and usb_disable_device() is called
> >>>>>>>
> >>>>>>> At this point all interface drivers get unbound (their disconnect 
> >>>>>>> routines are called).
> >>>>>>>
> >>>>>>>> - usb_disable_device() starts removing actconfig data. It has removed
> >>>>>>>>   and cleared dev->actconfig->interface[i], but not dev->actconfig
> >>>>>>>> - usb_set_interface() calls usb_hcd_alloc_bandwidth(), which calls
> >>>>>>>>   usb_ifnum_to_if()
> >>>>>>>> - In usb_ifnum_to_if(), dev->actconfig is not NULL, but
> >>>>>>>>   dev->actconfig->interface[i] is NULL
> >>>>>>>> - crash
> >>>>>>>>
> >>>>>>>> Question is what we can do about this. Checking if dev->state != USB_STATE_NOTATTACHED
> >>>>>>>> in usb_ifnum_to_if() might be a possible approach, but strictly speaking it would
> >>>>>>>> still be racy since there is still no lock against device removal. I have not tried
> >>>>>>>> calling usb_lock_device() in usb_set_interface() - would that possibly be an option ?
> >>>>>>>
> >>>>>>> As far as I know, protecting against these races is the responsibility 
> >>>>>>> of the USB interface drivers.  They must make sure that their disconnect 
> >>>>>>> routines block until all outstanding calls to usb_set_interface return 
> >>>>>>> (in fact, until all outstanding device accesses have finished).
> >>>>>>>
> >>>>>>> For instance, in the log extract you showed, it's obvious that the 
> >>>>>>> uvc_start_streaming routine was running after the disconnect routine had 
> >>>>>>> returned, which looks like a bug in itself: Once the disconnect routine 
> >>>>>>> returns, the driver is not supposed to try to access the device at all 
> >>>>>>> because some other driver may now be bound to it.
> >>>>>>>
> >>>>>>> We can't just call usb_lock_device from within usb_set_interface, 
> >>>>>>> because usb_set_interface is often called with that lock already held.
> >>>>>>>
> >>>>>> I had a closer look into the uvcvideo driver and compared it to other usb
> >>>>>> drivers, including drivers in drivers/media/usb/ which connect to the video
> >>>>>> subsystem.
> >>>>>>
> >>>>>> The usbvideo driver lacks protection against calls to uvc_disconnect() while
> >>>>>
> >>>>> Are you confusing usbvideo and uvcvideo ? Both exist, and uvcvideo would
> >>>>> have been called usbvideo if the former hadn't already been in use.
> >>>>
> >>>> Yes, sorry :-(. I am not sure how s/uvc/usb/ happened.
> >>>
> >>> No worries.
> >>>
> >>>>>> calls into file operations are ongoing. This is pretty widespread, and not
> >>>>>> even limited to file operations (for example, there is a worker which is only
> >>>>>> canceled in uvc_delete, not in ucv_disconnect). The existing protection only
> >>>>>> ensures that no file operations are started after the call to ucv_disconnect,
> >>>>>> but that is insufficient.
> >>>>>>
> >>>>>> Other drivers do have that protection and make sure that no usb operations
> >>>>>> can happen after the disconnect call.
> >>>>>>
> >>>>>> The only remedy I can see is to rework the usbvideo driver and add the
> >>>>>> necessary protections. At first glance, it looks like this may be a
> >>>>>> substantial amount of work. I'd sign up for that, but before I start,
> >>>>>> I would like to get input from the usbvideo community. Is such an effort
> >>>>>> already going on ? If yes, how can I help ? If not, is the problem
> >>>>>> understood and accepted ? Are there any ideas on how to solve it ?
> >>>>>
> >>>>> This is something that has been discussed before, and needs to be solved
> >>>>> in the V4L2 framework itself, not in individual drivers. Not only would
> >>>>> this avoid rolling out the same code manually everywhere (in different
> >>>>> incorrect ways, as races are difficult to solve and implementations are
> >>>>> more often wrong than right), but it will also avoid similar issues for
> >>>>> non-USB devices.
> >>>>
> >>>> You mean code that ensures that no user-space v4l2 operation is in progress
> >>>> after video_device_unregister / v4l2_device_unregister return ? I agree,
> >>>> that would simplify the necessary changes on the uvc side.
> >>>
> >>> I was thinking about adding a new function to be called from the
> >>> disconnect handler to implement the wait on end of userspace access, but
> >>> video_device_unregister() seems an even better idea.
> >>> v4l2_device_unregister() is probably not very useful as v4l2_device
> >>> isn't exposed to userspace, only video_device is (and v4l2_subdev and
> >>> media_device, but that's a different story, although probably still an
> >>> issue for the latter in the UVC driver).
> >>
> >> Actually, all that is needed is to take the ioctl serialization lock in the disconnect
> >> function.
> > 
> > It's not just ioctls though, the other file operations also need to be
> > handled (read, write, mmap).
> 
> Correct. And AFAIK all vb2-based drivers do take that serialization lock in
> the file ops.
> 
> >> See last paragraph in 1.4.1 here:
> >>
> >> https://hverkuil.home.xs4all.nl/spec/driver-api/v4l2-dev.html
> >>
> >> Since uvc uses its own lock, you need to take that one.
> > 
> > Drivers that use their own lock do so to avoid serializing all ioctls.
> 
> Let's agree to disagree :-)
> 
> In my experience it is just too hard to keep track of locking and with
> very little advantages. You are the only developer that I know of that
> insists on doing your own locking. Luckily you are very good at your
> job, but everyone else uses the v4l2/vb2 core locking.
> 
> > This means that different ioctls may be covered by different locks
> > (possibly with part of some ioctls running without locking). I don't
> > think we can just dismiss the issue saying those drivers need to
> > implement the disconnection manually. It would be much better to
> > integrate handling of userspace access with video_device_unregister()
> > like proposed above, as that will work for all drivers in a transparent
> > way. It would also be fairly simple to implement in the V4L2 core.
> 
> I'm not really sure what you want. Should video_unregister_device()
> take the core lock (i.e. vdev->lock)?

struct video_device {
	...
	wait_queue_head_t uapi_wait;
	bool uapi_call_in_progress;
	bool unregister_in_progress;
	...
};

static inline int video_device_uapi_call_enter(struct video_device *vdev)
{
	int ret = 0;

	spin_lock(&vdev->uapi_wait.lock);
	if (likely(!vdev->unregister_in_progress)) {
		vdev->uapi_call_in_progress = true;
	} else {
		ret = -ENOTCONN;
	}
	spin_unlock(&vdev->uapi_wait.lock);

	return ret;
}

static inline void video_device_uapi_call_exit(struct video_device *vdev)
{
	spin_lock(&vdev->uapi_wait.lock);
	vdev->uapi_call_in_progress = false;
	wake_up_locked(&vdev->uapi_wait);
	spin_unlock(&vdev->uapi_wait.lock);
}

void video_unregister_device(struct video_device *vdev)
{
	...


	...
}

 void video_unregister_device(struct video_device *vdev)
 {
 	/* Check if vdev was ever registered at all */
 	if (!vdev || !video_is_registered(vdev))
 		return;
 
+	spin_lock(&vdev->uapi_wait.lock);
+	vdev->unregister_in_progress = true;
+	if (vdev->uapi_call_in_progress)
+		wait_event_interruptible_locked(vdev->uapi_wait,
+						!vdev->uapi_call_in_progress);
+	spin_unlock(&vdev->uapi_wait.lock);
+
 	mutex_lock(&videodev_lock);
 	/* This must be in a critical section to prevent a race with v4l2_open.
 	 * Once this bit has been cleared video_get may never be called again.
 	 */
 	clear_bit(V4L2_FL_REGISTERED, &vdev->flags);
 	mutex_unlock(&videodev_lock);
 	device_unregister(&vdev->dev);
 }

 static long v4l2_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 {
 	struct video_device *vdev = video_devdata(filp);
-	int ret = -ENODEV;
+	int ret;
 
+	ret = video_device_uapi_call_enter(vdev);
+	if (ret)
+		return ret;
+
 	if (vdev->fops->unlocked_ioctl) {
 		if (video_is_registered(vdev))
 			ret = vdev->fops->unlocked_ioctl(filp, cmd, arg);
+		else
+			ret = -ENODEV;
 	} else
 		ret = -ENOTTY;
 
+	video_device_uapi_call_exit(vdev);
+
 	return ret;
 }

and similarly for the other fops. A bit more work is needed to merge
unregister_in_progress with the V4L2_FL_REGISTERED bit.

> >>> We also have a v4l2_device_disconnect() function which is supposed to
> >>> handle hot-pluggable device disconnection, but it's fairly useless (I'd
> >>> even say harmful as it gives the illusion that hotplugging is correctly
> >>> handled, while in reality the media subsystem is plagged by hot-unplug
> >>> issues :-S).
> >>
> >> The v4l2_device_disconnect() is there to remove a v4l2_dev reference to
> >> the device that is about to be removed when the disconnect() exists.
> >> Otherwise v4l2_dev->dev would point to a missing device.
> >>
> >> However, I wonder if it is still needed: commit 236c5441d703 from 2011 added
> >> code to take a reference to v4l2_dev->dev in v4l2_device_register(). This
> >> should prevent the device from disappearing until v4l2_device_unregister() is
> >> called. I suspect that v4l2_device_disconnect() can be removed completely, and
> >> instead v4l2_device_unregister() just calls put_device(v4l2_dev->dev).
> >>
> >> I don't like v4l2_device_disconnect() either, so if this works, then that would
> >> be a nice simplification.
> >>
> >>>> I actually came from the other side - I assumed that there is a reason
> >>>> that is not already the case, and that the problem therefore has to be
> >>>> resolved on the driver side.
> >>>>
> >>>> So I guess the next question is: Is this already being addressed on the
> >>>> v4l2 side ?
> >>>
> >>> I'm not aware of anyone working on this.
> >>>
> >>>>> It shouldn't take more than two flags (to track user-space operations in
> >>>>> progress and disconnection), a spinlock and a wait queue entry. I'm not
> >>>>> sure if someone has already given it a try, and don't recall why this
> >>>>> hasn't been done yet, as it should be fairly straightforward.
> >>>>>
> >>>>> On the UVC side, the work queue probably has to be flushed in
> >>>>> uvc_disconnect(). I'd keep the destroy call in uvc_delete() though.
> >>>>> Please make sure to look for potential race conditions between the URB
> >>>>> completion handler and the .disconnect() handler (they shouldn't be any,
> >>>>> but I haven't checked lately myself).
> >>>>
> >>>> My current solution for this problem is to call uvc_ctrl_cleanup_device()
> >>>> from uvc_disconnect(), after uvc_unregister_video().
> >>>
> >>> I'd rather avoid that, as the cleanup functions in the UVC driver are
> >>> generally meant to free memory when the last user disappears. While no
> >>> new userspace operation will be started after disconnection once the
> >>> above fix will be in place, there's one operation we can't avoid: the
> >>> file release. This will access some of the memory allocated by the
> >>> driver, and while the current implementation probably doesn't access in
> >>> .release() any memory freed by uvc_ctrl_cleanup_device(), I think it's a
> >>> good practice to only shut down the userspace API in .disconnect(), and
> >>> free memory when the last reference is released.
> >>>
> >>>> An alternative might
> >>>> be to add a uvc_ctrl_stop_device() function which would just cancel the
> >>>> worker.
> >>>
> >>> I think that would be best. Should stream->async_wq (in uvc_video.c) be
> >>> similarly flushed ? The driver does so in stream->async_wq(), called
> >>> from uvc_video_stop_transfer(), itself called from
> >>> uvc_video_stop_streaming() (among other places, that are either error
> >>> paths or system suspend handling). The call stack goes to
> >>> uvc_stop_streaming(), and, through the videobuf2 helpers, to
> >>> vb2_queue_release() called by uvc_queue_release() itself called by
> >>> uvc_v4l2_release() (in the non-disconnect case,
> >>> uvc_video_stop_streaming() will be called through videobuf2 by
> >>> uvc_queue_streamoff(), in response to a VIDIOC_STREAMOFF ioctl). We thus
> >>> flush the workqueue too late, and also access the device in
> >>> uvc_video_stop_streaming() long after .disconnect() returns.
> >>>
> >>> I think uvc_video_stop_streaming() could be called in uvc_disconnect()
> >>> after uvc_unregister_video().

-- 
Regards,

Laurent Pinchart

Re: [linux-uvc-devel] Protecting uvcvideo againt USB device disconnect [Was: Re: Protecting usb_set_interface() against device removal]

[Laurent P. <lau...@id...>]

Hi Hans,

On Mon, Aug 17, 2020 at 01:00:49PM +0200, Hans Verkuil wrote:
> On 17/08/2020 01:51, Laurent Pinchart wrote:
> > On Sun, Aug 16, 2020 at 08:54:18AM -0700, Guenter Roeck wrote:
> >> On 8/16/20 5:18 AM, Laurent Pinchart wrote:
> >>> CC'ing Hans Verkuil and Sakari Ailus for the discussion about handling
> >>> file operations and disconnect in V4L2.
> >>>
> >>> On Sat, Aug 15, 2020 at 05:33:15PM -0700, Guenter Roeck wrote:
> >>>> + lin...@li...
> >>>> + lin...@vg...
> >>>> + lau...@id...
> >>>>
> >>>> and changed subject
> >>>>
> >>>> On Fri, Aug 14, 2020 at 10:07:39PM -0400, Alan Stern wrote:
> >>>>> On Fri, Aug 14, 2020 at 04:07:03PM -0700, Guenter Roeck wrote:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> over time, there have been a number of reports of crashes in usb_ifnum_to_if(),
> >>>>>> called from usb_hcd_alloc_bandwidth, which is in turn called from usb_set_interface().
> >>>>>> Examples are [1] [2] [3]. A typical backtrace is:
> >>>>>>
> >>>>>> <3>[ 3489.445468] intel_sst_acpi 808622A8:00: sst: Busy wait failed, cant send this msg
> >>>>>> <6>[ 3490.507273] usb 1-4: USB disconnect, device number 3
> >>>>>> <1>[ 3490.516670] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> >>>>>> <6>[ 3490.516680] PGD 0 P4D 0
> >>>>>> <4>[ 3490.516687] Oops: 0000 [#1] PREEMPT SMP PTI
> >>>>>> <4>[ 3490.516693] CPU: 0 PID: 5633 Comm: V4L2CaptureThre Not tainted 4.19.113-08536-g5d29ca36db06 #1
> >>>>>> <4>[ 3490.516696] Hardware name: GOOGLE Edgar, BIOS Google_Edgar.7287.167.156 03/25/2019
> >>>>>> <4>[ 3490.516706] RIP: 0010:usb_ifnum_to_if+0x29/0x40
> >>>>>> <4>[ 3490.516710] Code: ee 0f 1f 44 00 00 55 48 89 e5 48 8b 8f f8 03 00 00 48 85 c9 74 27 44 0f b6 41 04 4d 85 c0 74 1d 31 ff 48 8b 84 f9 98 00 00 00 <48> 8b 10 0f b6 52 02 39 f2 74 0a 48 ff c7 4c 39 c7 72 e5 31 c0 5d
> >>>>>> <4>[ 3490.516714] RSP: 0018:ffffa46f42a47a80 EFLAGS: 00010246
> >>>>>> <4>[ 3490.516718] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff904a396c9000
> >>>>>> <4>[ 3490.516721] RDX: ffff904a39641320 RSI: 0000000000000001 RDI: 0000000000000000
> >>>>>> <4>[ 3490.516724] RBP: ffffa46f42a47a80 R08: 0000000000000002 R09: 0000000000000000
> >>>>>> <4>[ 3490.516727] R10: 0000000000009975 R11: 0000000000000009 R12: 0000000000000000
> >>>>>> <4>[ 3490.516731] R13: ffff904a396b3800 R14: ffff904a39e88000 R15: 0000000000000000
> >>>>>> <4>[ 3490.516735] FS: 00007f396448e700(0000) GS:ffff904a3ba00000(0000) knlGS:0000000000000000
> >>>>>> <4>[ 3490.516738] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >>>>>> <4>[ 3490.516742] CR2: 0000000000000000 CR3: 000000016cb46000 CR4: 00000000001006f0
> >>>>>> <4>[ 3490.516745] Call Trace:
> >>>>>> <4>[ 3490.516756] usb_hcd_alloc_bandwidth+0x1ee/0x30f
> >>>>>> <4>[ 3490.516762] usb_set_interface+0x1a3/0x2b7
> >>>>>> <4>[ 3490.516773] uvc_video_start_transfer+0x29b/0x4b8 [uvcvideo]
> >>>>>> <4>[ 3490.516781] uvc_video_start_streaming+0x91/0xdd [uvcvideo]
> >>>>>> <4>[ 3490.516787] uvc_start_streaming+0x28/0x5d [uvcvideo]
> >>>>>> <4>[ 3490.516795] vb2_start_streaming+0x61/0x143 [videobuf2_common]
> >>>>>> <4>[ 3490.516801] vb2_core_streamon+0xf7/0x10f [videobuf2_common]
> >>>>>> <4>[ 3490.516807] uvc_queue_streamon+0x2e/0x41 [uvcvideo]
> >>>>>> <4>[ 3490.516814] uvc_ioctl_streamon+0x42/0x5c [uvcvideo]
> >>>>>> <4>[ 3490.516820] __video_do_ioctl+0x33d/0x42a
> >>>>>> <4>[ 3490.516826] video_usercopy+0x34e/0x5ff
> >>>>>> <4>[ 3490.516831] ? video_ioctl2+0x16/0x16
> >>>>>> <4>[ 3490.516837] v4l2_ioctl+0x46/0x53
> >>>>>> <4>[ 3490.516843] do_vfs_ioctl+0x50a/0x76f
> >>>>>> <4>[ 3490.516848] ksys_ioctl+0x58/0x83
> >>>>>> <4>[ 3490.516853] __x64_sys_ioctl+0x1a/0x1e
> >>>>>> <4>[ 3490.516858] do_syscall_64+0x54/0xde
> >>>>>>
> >>>>>> I have been able to reproduce the problem on a Chromebook by strategically placing
> >>>>>> msleep() calls into usb_set_interface() and usb_disable_device(). Ultimately, the
> >>>>>> problem boils down to lack of protection against device removal in usb_set_interface()
> >>>>>> [and/or possibly other callers of usb_ifnum_to_if()].
> >>>>>>
> >>>>>> Sequence of events is roughly as follows:
> >>>>>>
> >>>>>> - usb_set_interface() is called and proceeds to some point, possibly to
> >>>>>>   mutex_lock(hcd->bandwidth_mutex);
> >>>>>> - Device removal event is detected, and usb_disable_device() is called
> >>>>>
> >>>>> At this point all interface drivers get unbound (their disconnect 
> >>>>> routines are called).
> >>>>>
> >>>>>> - usb_disable_device() starts removing actconfig data. It has removed
> >>>>>>   and cleared dev->actconfig->interface[i], but not dev->actconfig
> >>>>>> - usb_set_interface() calls usb_hcd_alloc_bandwidth(), which calls
> >>>>>>   usb_ifnum_to_if()
> >>>>>> - In usb_ifnum_to_if(), dev->actconfig is not NULL, but
> >>>>>>   dev->actconfig->interface[i] is NULL
> >>>>>> - crash
> >>>>>>
> >>>>>> Question is what we can do about this. Checking if dev->state != USB_STATE_NOTATTACHED
> >>>>>> in usb_ifnum_to_if() might be a possible approach, but strictly speaking it would
> >>>>>> still be racy since there is still no lock against device removal. I have not tried
> >>>>>> calling usb_lock_device() in usb_set_interface() - would that possibly be an option ?
> >>>>>
> >>>>> As far as I know, protecting against these races is the responsibility 
> >>>>> of the USB interface drivers.  They must make sure that their disconnect 
> >>>>> routines block until all outstanding calls to usb_set_interface return 
> >>>>> (in fact, until all outstanding device accesses have finished).
> >>>>>
> >>>>> For instance, in the log extract you showed, it's obvious that the 
> >>>>> uvc_start_streaming routine was running after the disconnect routine had 
> >>>>> returned, which looks like a bug in itself: Once the disconnect routine 
> >>>>> returns, the driver is not supposed to try to access the device at all 
> >>>>> because some other driver may now be bound to it.
> >>>>>
> >>>>> We can't just call usb_lock_device from within usb_set_interface, 
> >>>>> because usb_set_interface is often called with that lock already held.
> >>>>>
> >>>> I had a closer look into the uvcvideo driver and compared it to other usb
> >>>> drivers, including drivers in drivers/media/usb/ which connect to the video
> >>>> subsystem.
> >>>>
> >>>> The usbvideo driver lacks protection against calls to uvc_disconnect() while
> >>>
> >>> Are you confusing usbvideo and uvcvideo ? Both exist, and uvcvideo would
> >>> have been called usbvideo if the former hadn't already been in use.
> >>
> >> Yes, sorry :-(. I am not sure how s/uvc/usb/ happened.
> > 
> > No worries.
> > 
> >>>> calls into file operations are ongoing. This is pretty widespread, and not
> >>>> even limited to file operations (for example, there is a worker which is only
> >>>> canceled in uvc_delete, not in ucv_disconnect). The existing protection only
> >>>> ensures that no file operations are started after the call to ucv_disconnect,
> >>>> but that is insufficient.
> >>>>
> >>>> Other drivers do have that protection and make sure that no usb operations
> >>>> can happen after the disconnect call.
> >>>>
> >>>> The only remedy I can see is to rework the usbvideo driver and add the
> >>>> necessary protections. At first glance, it looks like this may be a
> >>>> substantial amount of work. I'd sign up for that, but before I start,
> >>>> I would like to get input from the usbvideo community. Is such an effort
> >>>> already going on ? If yes, how can I help ? If not, is the problem
> >>>> understood and accepted ? Are there any ideas on how to solve it ?
> >>>
> >>> This is something that has been discussed before, and needs to be solved
> >>> in the V4L2 framework itself, not in individual drivers. Not only would
> >>> this avoid rolling out the same code manually everywhere (in different
> >>> incorrect ways, as races are difficult to solve and implementations are
> >>> more often wrong than right), but it will also avoid similar issues for
> >>> non-USB devices.
> >>
> >> You mean code that ensures that no user-space v4l2 operation is in progress
> >> after video_device_unregister / v4l2_device_unregister return ? I agree,
> >> that would simplify the necessary changes on the uvc side.
> > 
> > I was thinking about adding a new function to be called from the
> > disconnect handler to implement the wait on end of userspace access, but
> > video_device_unregister() seems an even better idea.
> > v4l2_device_unregister() is probably not very useful as v4l2_device
> > isn't exposed to userspace, only video_device is (and v4l2_subdev and
> > media_device, but that's a different story, although probably still an
> > issue for the latter in the UVC driver).
> 
> Actually, all that is needed is to take the ioctl serialization lock in the disconnect
> function.

It's not just ioctls though, the other file operations also need to be
handled (read, write, mmap).

> See last paragraph in 1.4.1 here:
> 
> https://hverkuil.home.xs4all.nl/spec/driver-api/v4l2-dev.html
> 
> Since uvc uses its own lock, you need to take that one.

Drivers that use their own lock do so to avoid serializing all ioctls.
This means that different ioctls may be covered by different locks
(possibly with part of some ioctls running without locking). I don't
think we can just dismiss the issue saying those drivers need to
implement the disconnection manually. It would be much better to
integrate handling of userspace access with video_device_unregister()
like proposed above, as that will work for all drivers in a transparent
way. It would also be fairly simple to implement in the V4L2 core.

> > We also have a v4l2_device_disconnect() function which is supposed to
> > handle hot-pluggable device disconnection, but it's fairly useless (I'd
> > even say harmful as it gives the illusion that hotplugging is correctly
> > handled, while in reality the media subsystem is plagged by hot-unplug
> > issues :-S).
> 
> The v4l2_device_disconnect() is there to remove a v4l2_dev reference to
> the device that is about to be removed when the disconnect() exists.
> Otherwise v4l2_dev->dev would point to a missing device.
> 
> However, I wonder if it is still needed: commit 236c5441d703 from 2011 added
> code to take a reference to v4l2_dev->dev in v4l2_device_register(). This
> should prevent the device from disappearing until v4l2_device_unregister() is
> called. I suspect that v4l2_device_disconnect() can be removed completely, and
> instead v4l2_device_unregister() just calls put_device(v4l2_dev->dev).
> 
> I don't like v4l2_device_disconnect() either, so if this works, then that would
> be a nice simplification.
> 
> >> I actually came from the other side - I assumed that there is a reason
> >> that is not already the case, and that the problem therefore has to be
> >> resolved on the driver side.
> >>
> >> So I guess the next question is: Is this already being addressed on the
> >> v4l2 side ?
> > 
> > I'm not aware of anyone working on this.
> > 
> >>> It shouldn't take more than two flags (to track user-space operations in
> >>> progress and disconnection), a spinlock and a wait queue entry. I'm not
> >>> sure if someone has already given it a try, and don't recall why this
> >>> hasn't been done yet, as it should be fairly straightforward.
> >>>
> >>> On the UVC side, the work queue probably has to be flushed in
> >>> uvc_disconnect(). I'd keep the destroy call in uvc_delete() though.
> >>> Please make sure to look for potential race conditions between the URB
> >>> completion handler and the .disconnect() handler (they shouldn't be any,
> >>> but I haven't checked lately myself).
> >>
> >> My current solution for this problem is to call uvc_ctrl_cleanup_device()
> >> from uvc_disconnect(), after uvc_unregister_video().
> > 
> > I'd rather avoid that, as the cleanup functions in the UVC driver are
> > generally meant to free memory when the last user disappears. While no
> > new userspace operation will be started after disconnection once the
> > above fix will be in place, there's one operation we can't avoid: the
> > file release. This will access some of the memory allocated by the
> > driver, and while the current implementation probably doesn't access in
> > .release() any memory freed by uvc_ctrl_cleanup_device(), I think it's a
> > good practice to only shut down the userspace API in .disconnect(), and
> > free memory when the last reference is released.
> > 
> >> An alternative might
> >> be to add a uvc_ctrl_stop_device() function which would just cancel the
> >> worker.
> > 
> > I think that would be best. Should stream->async_wq (in uvc_video.c) be
> > similarly flushed ? The driver does so in stream->async_wq(), called
> > from uvc_video_stop_transfer(), itself called from
> > uvc_video_stop_streaming() (among other places, that are either error
> > paths or system suspend handling). The call stack goes to
> > uvc_stop_streaming(), and, through the videobuf2 helpers, to
> > vb2_queue_release() called by uvc_queue_release() itself called by
> > uvc_v4l2_release() (in the non-disconnect case,
> > uvc_video_stop_streaming() will be called through videobuf2 by
> > uvc_queue_streamoff(), in response to a VIDIOC_STREAMOFF ioctl). We thus
> > flush the workqueue too late, and also access the device in
> > uvc_video_stop_streaming() long after .disconnect() returns.
> > 
> > I think uvc_video_stop_streaming() could be called in uvc_disconnect()
> > after uvc_unregister_video().

-- 
Regards,

Laurent Pinchart

Re: [linux-uvc-devel] Protecting uvcvideo againt USB device disconnect [Was: Re: Protecting usb_set_interface() against device removal]

[Laurent P. <lau...@id...>]

Hi Guenter,

On Sun, Aug 16, 2020 at 08:54:18AM -0700, Guenter Roeck wrote:
> On 8/16/20 5:18 AM, Laurent Pinchart wrote:
> > Hi Guenter,
> > 
> > CC'ing Hans Verkuil and Sakari Ailus for the discussion about handling
> > file operations and disconnect in V4L2.
> > 
> > On Sat, Aug 15, 2020 at 05:33:15PM -0700, Guenter Roeck wrote:
> >> + lin...@li...
> >> + lin...@vg...
> >> + lau...@id...
> >>
> >> and changed subject
> >>
> >> On Fri, Aug 14, 2020 at 10:07:39PM -0400, Alan Stern wrote:
> >>> On Fri, Aug 14, 2020 at 04:07:03PM -0700, Guenter Roeck wrote:
> >>>> Hi all,
> >>>>
> >>>> over time, there have been a number of reports of crashes in usb_ifnum_to_if(),
> >>>> called from usb_hcd_alloc_bandwidth, which is in turn called from usb_set_interface().
> >>>> Examples are [1] [2] [3]. A typical backtrace is:
> >>>>
> >>>> <3>[ 3489.445468] intel_sst_acpi 808622A8:00: sst: Busy wait failed, cant send this msg
> >>>> <6>[ 3490.507273] usb 1-4: USB disconnect, device number 3
> >>>> <1>[ 3490.516670] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> >>>> <6>[ 3490.516680] PGD 0 P4D 0
> >>>> <4>[ 3490.516687] Oops: 0000 [#1] PREEMPT SMP PTI
> >>>> <4>[ 3490.516693] CPU: 0 PID: 5633 Comm: V4L2CaptureThre Not tainted 4.19.113-08536-g5d29ca36db06 #1
> >>>> <4>[ 3490.516696] Hardware name: GOOGLE Edgar, BIOS Google_Edgar.7287.167.156 03/25/2019
> >>>> <4>[ 3490.516706] RIP: 0010:usb_ifnum_to_if+0x29/0x40
> >>>> <4>[ 3490.516710] Code: ee 0f 1f 44 00 00 55 48 89 e5 48 8b 8f f8 03 00 00 48 85 c9 74 27 44 0f b6 41 04 4d 85 c0 74 1d 31 ff 48 8b 84 f9 98 00 00 00 <48> 8b 10 0f b6 52 02 39 f2 74 0a 48 ff c7 4c 39 c7 72 e5 31 c0 5d
> >>>> <4>[ 3490.516714] RSP: 0018:ffffa46f42a47a80 EFLAGS: 00010246
> >>>> <4>[ 3490.516718] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff904a396c9000
> >>>> <4>[ 3490.516721] RDX: ffff904a39641320 RSI: 0000000000000001 RDI: 0000000000000000
> >>>> <4>[ 3490.516724] RBP: ffffa46f42a47a80 R08: 0000000000000002 R09: 0000000000000000
> >>>> <4>[ 3490.516727] R10: 0000000000009975 R11: 0000000000000009 R12: 0000000000000000
> >>>> <4>[ 3490.516731] R13: ffff904a396b3800 R14: ffff904a39e88000 R15: 0000000000000000
> >>>> <4>[ 3490.516735] FS: 00007f396448e700(0000) GS:ffff904a3ba00000(0000) knlGS:0000000000000000
> >>>> <4>[ 3490.516738] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >>>> <4>[ 3490.516742] CR2: 0000000000000000 CR3: 000000016cb46000 CR4: 00000000001006f0
> >>>> <4>[ 3490.516745] Call Trace:
> >>>> <4>[ 3490.516756] usb_hcd_alloc_bandwidth+0x1ee/0x30f
> >>>> <4>[ 3490.516762] usb_set_interface+0x1a3/0x2b7
> >>>> <4>[ 3490.516773] uvc_video_start_transfer+0x29b/0x4b8 [uvcvideo]
> >>>> <4>[ 3490.516781] uvc_video_start_streaming+0x91/0xdd [uvcvideo]
> >>>> <4>[ 3490.516787] uvc_start_streaming+0x28/0x5d [uvcvideo]
> >>>> <4>[ 3490.516795] vb2_start_streaming+0x61/0x143 [videobuf2_common]
> >>>> <4>[ 3490.516801] vb2_core_streamon+0xf7/0x10f [videobuf2_common]
> >>>> <4>[ 3490.516807] uvc_queue_streamon+0x2e/0x41 [uvcvideo]
> >>>> <4>[ 3490.516814] uvc_ioctl_streamon+0x42/0x5c [uvcvideo]
> >>>> <4>[ 3490.516820] __video_do_ioctl+0x33d/0x42a
> >>>> <4>[ 3490.516826] video_usercopy+0x34e/0x5ff
> >>>> <4>[ 3490.516831] ? video_ioctl2+0x16/0x16
> >>>> <4>[ 3490.516837] v4l2_ioctl+0x46/0x53
> >>>> <4>[ 3490.516843] do_vfs_ioctl+0x50a/0x76f
> >>>> <4>[ 3490.516848] ksys_ioctl+0x58/0x83
> >>>> <4>[ 3490.516853] __x64_sys_ioctl+0x1a/0x1e
> >>>> <4>[ 3490.516858] do_syscall_64+0x54/0xde
> >>>>
> >>>> I have been able to reproduce the problem on a Chromebook by strategically placing
> >>>> msleep() calls into usb_set_interface() and usb_disable_device(). Ultimately, the
> >>>> problem boils down to lack of protection against device removal in usb_set_interface()
> >>>> [and/or possibly other callers of usb_ifnum_to_if()].
> >>>>
> >>>> Sequence of events is roughly as follows:
> >>>>
> >>>> - usb_set_interface() is called and proceeds to some point, possibly to
> >>>>   mutex_lock(hcd->bandwidth_mutex);
> >>>> - Device removal event is detected, and usb_disable_device() is called
> >>>
> >>> At this point all interface drivers get unbound (their disconnect 
> >>> routines are called).
> >>>
> >>>> - usb_disable_device() starts removing actconfig data. It has removed
> >>>>   and cleared dev->actconfig->interface[i], but not dev->actconfig
> >>>> - usb_set_interface() calls usb_hcd_alloc_bandwidth(), which calls
> >>>>   usb_ifnum_to_if()
> >>>> - In usb_ifnum_to_if(), dev->actconfig is not NULL, but
> >>>>   dev->actconfig->interface[i] is NULL
> >>>> - crash
> >>>>
> >>>> Question is what we can do about this. Checking if dev->state != USB_STATE_NOTATTACHED
> >>>> in usb_ifnum_to_if() might be a possible approach, but strictly speaking it would
> >>>> still be racy since there is still no lock against device removal. I have not tried
> >>>> calling usb_lock_device() in usb_set_interface() - would that possibly be an option ?
> >>>
> >>> As far as I know, protecting against these races is the responsibility 
> >>> of the USB interface drivers.  They must make sure that their disconnect 
> >>> routines block until all outstanding calls to usb_set_interface return 
> >>> (in fact, until all outstanding device accesses have finished).
> >>>
> >>> For instance, in the log extract you showed, it's obvious that the 
> >>> uvc_start_streaming routine was running after the disconnect routine had 
> >>> returned, which looks like a bug in itself: Once the disconnect routine 
> >>> returns, the driver is not supposed to try to access the device at all 
> >>> because some other driver may now be bound to it.
> >>>
> >>> We can't just call usb_lock_device from within usb_set_interface, 
> >>> because usb_set_interface is often called with that lock already held.
> >>>
> >> I had a closer look into the uvcvideo driver and compared it to other usb
> >> drivers, including drivers in drivers/media/usb/ which connect to the video
> >> subsystem.
> >>
> >> The usbvideo driver lacks protection against calls to uvc_disconnect() while
> > 
> > Are you confusing usbvideo and uvcvideo ? Both exist, and uvcvideo would
> > have been called usbvideo if the former hadn't already been in use.
> 
> Yes, sorry :-(. I am not sure how s/uvc/usb/ happened.

No worries.

> >> calls into file operations are ongoing. This is pretty widespread, and not
> >> even limited to file operations (for example, there is a worker which is only
> >> canceled in uvc_delete, not in ucv_disconnect). The existing protection only
> >> ensures that no file operations are started after the call to ucv_disconnect,
> >> but that is insufficient.
> >>
> >> Other drivers do have that protection and make sure that no usb operations
> >> can happen after the disconnect call.
> >>
> >> The only remedy I can see is to rework the usbvideo driver and add the
> >> necessary protections. At first glance, it looks like this may be a
> >> substantial amount of work. I'd sign up for that, but before I start,
> >> I would like to get input from the usbvideo community. Is such an effort
> >> already going on ? If yes, how can I help ? If not, is the problem
> >> understood and accepted ? Are there any ideas on how to solve it ?
> > 
> > This is something that has been discussed before, and needs to be solved
> > in the V4L2 framework itself, not in individual drivers. Not only would
> > this avoid rolling out the same code manually everywhere (in different
> > incorrect ways, as races are difficult to solve and implementations are
> > more often wrong than right), but it will also avoid similar issues for
> > non-USB devices.
>
> You mean code that ensures that no user-space v4l2 operation is in progress
> after video_device_unregister / v4l2_device_unregister return ? I agree,
> that would simplify the necessary changes on the uvc side.

I was thinking about adding a new function to be called from the
disconnect handler to implement the wait on end of userspace access, but
video_device_unregister() seems an even better idea.
v4l2_device_unregister() is probably not very useful as v4l2_device
isn't exposed to userspace, only video_device is (and v4l2_subdev and
media_device, but that's a different story, although probably still an
issue for the latter in the UVC driver).

We also have a v4l2_device_disconnect() function which is supposed to
handle hot-pluggable device disconnection, but it's fairly useless (I'd
even say harmful as it gives the illusion that hotplugging is correctly
handled, while in reality the media subsystem is plagged by hot-unplug
issues :-S).

> I actually came from the other side - I assumed that there is a reason
> that is not already the case, and that the problem therefore has to be
> resolved on the driver side.
> 
> So I guess the next question is: Is this already being addressed on the
> v4l2 side ?

I'm not aware of anyone working on this.

> > It shouldn't take more than two flags (to track user-space operations in
> > progress and disconnection), a spinlock and a wait queue entry. I'm not
> > sure if someone has already given it a try, and don't recall why this
> > hasn't been done yet, as it should be fairly straightforward.
> > 
> > On the UVC side, the work queue probably has to be flushed in
> > uvc_disconnect(). I'd keep the destroy call in uvc_delete() though.
> > Please make sure to look for potential race conditions between the URB
> > completion handler and the .disconnect() handler (they shouldn't be any,
> > but I haven't checked lately myself).
>
> My current solution for this problem is to call uvc_ctrl_cleanup_device()
> from uvc_disconnect(), after uvc_unregister_video().

I'd rather avoid that, as the cleanup functions in the UVC driver are
generally meant to free memory when the last user disappears. While no
new userspace operation will be started after disconnection once the
above fix will be in place, there's one operation we can't avoid: the
file release. This will access some of the memory allocated by the
driver, and while the current implementation probably doesn't access in
.release() any memory freed by uvc_ctrl_cleanup_device(), I think it's a
good practice to only shut down the userspace API in .disconnect(), and
free memory when the last reference is released.

> An alternative might
> be to add a uvc_ctrl_stop_device() function which would just cancel the
> worker.

I think that would be best. Should stream->async_wq (in uvc_video.c) be
similarly flushed ? The driver does so in stream->async_wq(), called
from uvc_video_stop_transfer(), itself called from
uvc_video_stop_streaming() (among other places, that are either error
paths or system suspend handling). The call stack goes to
uvc_stop_streaming(), and, through the videobuf2 helpers, to
vb2_queue_release() called by uvc_queue_release() itself called by
uvc_v4l2_release() (in the non-disconnect case,
uvc_video_stop_streaming() will be called through videobuf2 by
uvc_queue_streamoff(), in response to a VIDIOC_STREAMOFF ioctl). We thus
flush the workqueue too late, and also access the device in
uvc_video_stop_streaming() long after .disconnect() returns.

I think uvc_video_stop_streaming() could be called in uvc_disconnect()
after uvc_unregister_video().

-- 
Regards,

Laurent Pinchart

Re: [linux-uvc-devel] Protecting uvcvideo againt USB device disconnect [Was: Re: Protecting usb_set_interface() against device removal]

[Laurent P. <lau...@id...>]

Hi Guenter,

CC'ing Hans Verkuil and Sakari Ailus for the discussion about handling
file operations and disconnect in V4L2.

On Sat, Aug 15, 2020 at 05:33:15PM -0700, Guenter Roeck wrote:
> + lin...@li...
> + lin...@vg...
> + lau...@id...
> 
> and changed subject
> 
> On Fri, Aug 14, 2020 at 10:07:39PM -0400, Alan Stern wrote:
> > On Fri, Aug 14, 2020 at 04:07:03PM -0700, Guenter Roeck wrote:
> > > Hi all,
> > > 
> > > over time, there have been a number of reports of crashes in usb_ifnum_to_if(),
> > > called from usb_hcd_alloc_bandwidth, which is in turn called from usb_set_interface().
> > > Examples are [1] [2] [3]. A typical backtrace is:
> > > 
> > > <3>[ 3489.445468] intel_sst_acpi 808622A8:00: sst: Busy wait failed, cant send this msg
> > > <6>[ 3490.507273] usb 1-4: USB disconnect, device number 3
> > > <1>[ 3490.516670] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> > > <6>[ 3490.516680] PGD 0 P4D 0
> > > <4>[ 3490.516687] Oops: 0000 [#1] PREEMPT SMP PTI
> > > <4>[ 3490.516693] CPU: 0 PID: 5633 Comm: V4L2CaptureThre Not tainted 4.19.113-08536-g5d29ca36db06 #1
> > > <4>[ 3490.516696] Hardware name: GOOGLE Edgar, BIOS Google_Edgar.7287.167.156 03/25/2019
> > > <4>[ 3490.516706] RIP: 0010:usb_ifnum_to_if+0x29/0x40
> > > <4>[ 3490.516710] Code: ee 0f 1f 44 00 00 55 48 89 e5 48 8b 8f f8 03 00 00 48 85 c9 74 27 44 0f b6 41 04 4d 85 c0 74 1d 31 ff 48 8b 84 f9 98 00 00 00 <48> 8b 10 0f b6 52 02 39 f2 74 0a 48 ff c7 4c 39 c7 72 e5 31 c0 5d
> > > <4>[ 3490.516714] RSP: 0018:ffffa46f42a47a80 EFLAGS: 00010246
> > > <4>[ 3490.516718] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff904a396c9000
> > > <4>[ 3490.516721] RDX: ffff904a39641320 RSI: 0000000000000001 RDI: 0000000000000000
> > > <4>[ 3490.516724] RBP: ffffa46f42a47a80 R08: 0000000000000002 R09: 0000000000000000
> > > <4>[ 3490.516727] R10: 0000000000009975 R11: 0000000000000009 R12: 0000000000000000
> > > <4>[ 3490.516731] R13: ffff904a396b3800 R14: ffff904a39e88000 R15: 0000000000000000
> > > <4>[ 3490.516735] FS: 00007f396448e700(0000) GS:ffff904a3ba00000(0000) knlGS:0000000000000000
> > > <4>[ 3490.516738] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > <4>[ 3490.516742] CR2: 0000000000000000 CR3: 000000016cb46000 CR4: 00000000001006f0
> > > <4>[ 3490.516745] Call Trace:
> > > <4>[ 3490.516756] usb_hcd_alloc_bandwidth+0x1ee/0x30f
> > > <4>[ 3490.516762] usb_set_interface+0x1a3/0x2b7
> > > <4>[ 3490.516773] uvc_video_start_transfer+0x29b/0x4b8 [uvcvideo]
> > > <4>[ 3490.516781] uvc_video_start_streaming+0x91/0xdd [uvcvideo]
> > > <4>[ 3490.516787] uvc_start_streaming+0x28/0x5d [uvcvideo]
> > > <4>[ 3490.516795] vb2_start_streaming+0x61/0x143 [videobuf2_common]
> > > <4>[ 3490.516801] vb2_core_streamon+0xf7/0x10f [videobuf2_common]
> > > <4>[ 3490.516807] uvc_queue_streamon+0x2e/0x41 [uvcvideo]
> > > <4>[ 3490.516814] uvc_ioctl_streamon+0x42/0x5c [uvcvideo]
> > > <4>[ 3490.516820] __video_do_ioctl+0x33d/0x42a
> > > <4>[ 3490.516826] video_usercopy+0x34e/0x5ff
> > > <4>[ 3490.516831] ? video_ioctl2+0x16/0x16
> > > <4>[ 3490.516837] v4l2_ioctl+0x46/0x53
> > > <4>[ 3490.516843] do_vfs_ioctl+0x50a/0x76f
> > > <4>[ 3490.516848] ksys_ioctl+0x58/0x83
> > > <4>[ 3490.516853] __x64_sys_ioctl+0x1a/0x1e
> > > <4>[ 3490.516858] do_syscall_64+0x54/0xde
> > > 
> > > I have been able to reproduce the problem on a Chromebook by strategically placing
> > > msleep() calls into usb_set_interface() and usb_disable_device(). Ultimately, the
> > > problem boils down to lack of protection against device removal in usb_set_interface()
> > > [and/or possibly other callers of usb_ifnum_to_if()].
> > > 
> > > Sequence of events is roughly as follows:
> > > 
> > > - usb_set_interface() is called and proceeds to some point, possibly to
> > >   mutex_lock(hcd->bandwidth_mutex);
> > > - Device removal event is detected, and usb_disable_device() is called
> > 
> > At this point all interface drivers get unbound (their disconnect 
> > routines are called).
> > 
> > > - usb_disable_device() starts removing actconfig data. It has removed
> > >   and cleared dev->actconfig->interface[i], but not dev->actconfig
> > > - usb_set_interface() calls usb_hcd_alloc_bandwidth(), which calls
> > >   usb_ifnum_to_if()
> > > - In usb_ifnum_to_if(), dev->actconfig is not NULL, but
> > >   dev->actconfig->interface[i] is NULL
> > > - crash
> > > 
> > > Question is what we can do about this. Checking if dev->state != USB_STATE_NOTATTACHED
> > > in usb_ifnum_to_if() might be a possible approach, but strictly speaking it would
> > > still be racy since there is still no lock against device removal. I have not tried
> > > calling usb_lock_device() in usb_set_interface() - would that possibly be an option ?
> > 
> > As far as I know, protecting against these races is the responsibility 
> > of the USB interface drivers.  They must make sure that their disconnect 
> > routines block until all outstanding calls to usb_set_interface return 
> > (in fact, until all outstanding device accesses have finished).
> > 
> > For instance, in the log extract you showed, it's obvious that the 
> > uvc_start_streaming routine was running after the disconnect routine had 
> > returned, which looks like a bug in itself: Once the disconnect routine 
> > returns, the driver is not supposed to try to access the device at all 
> > because some other driver may now be bound to it.
> > 
> > We can't just call usb_lock_device from within usb_set_interface, 
> > because usb_set_interface is often called with that lock already held.
> > 
> I had a closer look into the uvcvideo driver and compared it to other usb
> drivers, including drivers in drivers/media/usb/ which connect to the video
> subsystem.
> 
> The usbvideo driver lacks protection against calls to uvc_disconnect() while

Are you confusing usbvideo and uvcvideo ? Both exist, and uvcvideo would
have been called usbvideo if the former hadn't already been in use.

> calls into file operations are ongoing. This is pretty widespread, and not
> even limited to file operations (for example, there is a worker which is only
> canceled in uvc_delete, not in ucv_disconnect). The existing protection only
> ensures that no file operations are started after the call to ucv_disconnect,
> but that is insufficient.
> 
> Other drivers do have that protection and make sure that no usb operations
> can happen after the disconnect call.
> 
> The only remedy I can see is to rework the usbvideo driver and add the
> necessary protections. At first glance, it looks like this may be a
> substantial amount of work. I'd sign up for that, but before I start,
> I would like to get input from the usbvideo community. Is such an effort
> already going on ? If yes, how can I help ? If not, is the problem
> understood and accepted ? Are there any ideas on how to solve it ?

This is something that has been discussed before, and needs to be solved
in the V4L2 framework itself, not in individual drivers. Not only would
this avoid rolling out the same code manually everywhere (in different
incorrect ways, as races are difficult to solve and implementations are
more often wrong than right), but it will also avoid similar issues for
non-USB devices.

It shouldn't take more than two flags (to track user-space operations in
progress and disconnection), a spinlock and a wait queue entry. I'm not
sure if someone has already given it a try, and don't recall why this
hasn't been done yet, as it should be fairly straightforward.

On the UVC side, the work queue probably has to be flushed in
uvc_disconnect(). I'd keep the destroy call in uvc_delete() though.
Please make sure to look for potential race conditions between the URB
completion handler and the .disconnect() handler (they shouldn't be any,
but I haven't checked lately myself).

-- 
Regards,

Laurent Pinchart

[linux-uvc-devel] Lenovo Thinkpad X240

[prajac <cha...@go...>]

Hello
I have a Lenovo Thinkpad X240 laptop and the integrated camera is not
working on the several linux distros I have tried (Feren, Mint, MX Linux,
Pop oS).
I have tried an external camera and it works.
The system info is as follows and does not list camera. Looking at forums I
think the camera may be Sunplus/Realtek

 Please find attached a system report I generated from Hardinfo software

Kind Regards
Chandra

[linux-uvc-devel] New camera for supported device list, and question

[Jack <ost...@us...>]

I just bought an inexpensive webcam from eBay
   Bus 001 Device 092: ID 13d3:784b IMC Networks Integrated Camera

I've attached lsusb.log.  When I run lsusb, I get
  can't get debug descriptor: Resource temporarily unavailable
although the file seems to be created without problem.

It was advertised as 1080P but pretty clearly only does 640x480.   
guvcview works fine, but I see a small number of
  [364052.640810] uvcvideo: Failed to query (GET_CUR) UVC control 3 on  
unit 1: -32 (exp. 1).
in dmesg.  VLC also works, but defaults to using yuyv, and when forced  
(command line) to use mjpg, I get repeated lines of
   [mjpeg @ 0x7f70440218c0] unable to decode APP fields: Invalid data  
found when processing input
to the console.

The camera claims to have a microphone, but there is a separate audio  
plug for that, so no usb sound.

Note I'm not asking for any help with the device, just reporting to add  
to the list of supported devices.

I'll be glad to do any additional testing or provide additional info if  
it will be of any use.

Jack

[linux-uvc-devel] Streaming h.264 video with ucv gadget application

[amit k. <aat...@gm...>]

Hi,
Is there any linux usb ucv gadget sample application to test h.264 video
stream with windows host?
Thanks,
Amit

Re: [linux-uvc-devel] Sound problem with new web cam

[Paul F. <fer...@gm...>]

On Thu, Jul 23, 2020 at 09:55:08AM -0400, Mike Diehl wrote:
> mdiehl@mikedesktop:~$ arecord -L
...
> hw:CARD=Camera,DEV=0
>    UVC Camera, USB Audio
>    Direct hardware device without any conversions
> plughw:CARD=Camera,DEV=0
>    UVC Camera, USB Audio
>    Hardware device with all software conversions
> usbstream:CARD=Camera
>    UVC Camera
>    USB Stream Output

So looks like it should just work, right? You should be able to tweak
recording levels with "alsamixer" (press F6 if wrong card is selected)
and you can try using something "arecord -Dhw:CARD=Camera test.wav" to
see if it works.

I guess it's now fairly obvious that this question is not related to
UVC but I'm ready to continue in private (or on IRC).

HTH
-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [linux-uvc-devel] Sound problem with new web cam

[Paul F. <fer...@gm...>]

Hi,

On Wed, Jul 22, 2020 at 07:05:53PM -0400, Mike Diehl wrote:
> And here is what I get from lsusb pd:
> 
> https://paste.ee/p/9Lcol

So it's a composite device that includes a sound card. Is
snd-usb-audio module getting loaded? Have you checked "arecord -L"
output?

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

[linux-uvc-devel] Sound problem with new web cam

[Mike D. <mdi...@gm...>]

Hi all,

So I bought a new web cam on Amazon that claimed that it had Linux support.  
When I plugged it in, it produced very nice graphics.  However, it didn't 
produce any (clear?) sound.

It did produce sound under Windoze.

I've tried different machines and have made all of the adjustments I could find 
under the sound manager in KDE and alsa.

Here is a copy/paste of the kernel messages when I plug it in:

https://paste.ee/p/rQByM

And here is what I get from lsusb pd:

https://paste.ee/p/9Lcol


This device doesn't seem to be listed in the Supported Devices list, but it 
clearly supports UVC and sound..  At the very least, an entry should be added 
for this device.


Any ideas on how to make it work properly?


-- 
Mike Diehl

Re: [linux-uvc-devel] Quanta Computer Inc. Astro HD Cam, not initializing at boot

[Massimo B. <mas...@gm...>]

Hi again,

booting up without that device, the first plugin also fails like mentioned. Only
unplugging and replugging again makes it work.

Best regards,
Massimo

On Wed, 2020-07-08 at 13:28 +0200, Massimo B. wrote:

...
> This chinese camera does not initialize correctly at boot:
>
> Bus 003 Device 004: ID 0408:2090 Quanta Computer, Inc. Astro HD Camera
>
> After replugging it works fine.
>
...
>
> When booting with this device plugged, it is not usable and blocking other
> audio
> devices:
>
> $ pacmd list-sources
> Daemon not responding.
>
> The syslog has continuously repeating this line:
>
> [kernel] usb 3-7: 4:1: cannot set freq 44100 to ep 0x84
> [kernel] usb 3-7: 4:1: cannot set freq 44100 to ep 0x84
>
> rmmod and modprob'ing uvcvideo again shows:
>
> [pulseaudio] [pulseaudio] module-alsa-card.c: Failed to find a working
> profile.
> [pulseaudio] [pulseaudio] module.c: Failed to load module "module-alsa-card"
> (argument: "device_id="0" name="usb-QCM_Astro_HD_Camera-03"
> card_name="alsa_card.usb-QCM_Astro_HD_Camera-03" namereg_fail=false tsched=yes
> fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes
> avoid_resampling=no card_properties="module-udev-detect.discovered=1""):
> initialization failed.
> [pulseaudio] [pulseaudio] module-udev-detect.c: Failed to open
> /proc/asound/card0: No such file or directory
> [kernel] uvcvideo: Failed to query (129) UVC probe control : -110 (exp. 26).
> [kernel] usb 3-7: 4:1: cannot set freq 44100 to ep 0x84
> [kernel] uvcvideo: Failed to initialize the device (-5).
> [kernel] usbcore: registered new interface driver uvcvideo
> [kernel] USB Video Class driver (1.1.1)
>
> Unplugging the usb cam, restarting pulseaudio and replugging the cam again
> makes
> it work:
>
> [kernel] usb 3-7: new high-speed USB device number 11 using xhci_hcd
> [kernel] usb 3-7: New USB device found, idVendor=0408, idProduct=2090,
> bcdDevice=21.17
> [kernel] usb 3-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [kernel] usb 3-7: Product: Astro HD Camera
> [kernel] usb 3-7: Manufacturer: QCM
> [kernel] uvcvideo: Found UVC 1.00 device Astro HD Camera (0408:2090)
> [kernel] uvcvideo: Unable to create debugfs 3-11-1 directory.
> [kernel] uvcvideo: No streaming interface found for terminal 9.
> [kernel] input: Astro HD Camera: Astro HD Camer as
> /devices/pci0000:00/0000:00:14.0/usb3/3-7/3-7:1.0/input/input21
> [mtp-probe] checking bus 3, device 11:
> "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-7"_
> [mtp-probe] bus: 3, device: 11 was not an MTP device_
> [laptop-mode] Laptop Mode Tools disabled in config file\n
> [laptop-mode] Laptop Mode Tools disabled in config file\n
> [laptop-mode] Laptop Mode Tools disabled in config file\n
> [mtp-probe] checking bus 3, device 11:
> "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-7"_
> [mtp-probe] bus: 3, device: 11 was not an MTP device_
> [pulseaudio] [pulseaudio] module-udev-detect.c: Failed to open
> /proc/asound/card0: No such file or directory
> [pulseaudio] [pulseaudio] utils.c: could not open configuration file
> /usr/share/alsa/ucm2/Astro HD Camera/Astro HD Camera.conf
> [pulseaudio] [pulseaudio] parser.c: error: could not parse configuration for
> card Astro HD Camera
> [pulseaudio] [pulseaudio] main.c: error: failed to import Astro HD Camera use
> case configuration -2
> [pulseaudio] [pulseaudio] alsa-ucm.c: UCM not available for card Astro HD
> Camera
> [pulseaudio] [pulseaudio] control.c: Invalid CTL front:0
> [pulseaudio] [pulseaudio] alsa-util.c: Unable to attach to mixer front:0: No
> such file or directory
> [pulseaudio] [pulseaudio] alsa-util.c: Successfully attached to mixer 'hw:0'
> [pulseaudio] [pulseaudio] control.c: Invalid CTL iec958:0
> [pulseaudio] [pulseaudio] alsa-util.c: Unable to attach to mixer iec958:0: No
> such file or directory
> [pulseaudio] [pulseaudio] alsa-util.c: Successfully attached to mixer 'hw:0'
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device front:0: No
> such file or directory
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device surround21:0:
> No such file or directory
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device surround40:0:
> No such file or directory
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device surround41:0:
> No such file or directory
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device surround50:0:
> No such file or directory
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device surround51:0:
> No such file or directory
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device surround71:0:
> No such file or directory
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device iec958:0: No
> such file or directory
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device a52:0: No such
> file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM dca:0
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device dca:0: No such
> file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0: No
> such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM dcahdmi:0
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:0: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.1:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,1
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,1: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.1:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,1
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,1: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.1:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,1
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,1: No
> such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM dcahdmi:0,1
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:0,1:
> No such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.2:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,2
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,2: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.2:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,2
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,2: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.2:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,2
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,2: No
> such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM dcahdmi:0,2
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:0,2:
> No such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.3:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,3
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,3: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.3:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,3
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,3: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.3:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,3
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,3: No
> such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM dcahdmi:0,3
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:0,3:
> No such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.4:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,4
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,4: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.4:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,4
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,4: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.4:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,4
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,4: No
> such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM dcahdmi:0,4
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:0,4:
> No such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.5:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,5
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,5: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.5:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,5
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,5: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.5:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,5
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,5: No
> such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM dcahdmi:0,5
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:0,5:
> No such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.6:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,6
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,6: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.6:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,6
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,6: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.6:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,6
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,6: No
> such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM dcahdmi:0,6
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:0,6:
> No such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.7:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,7
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,7: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.7:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,7
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,7: No
> such file or directory
> [pulseaudio] [pulseaudio] confmisc.c: Unable to find definition 'cards.USB-
> Audio.pcm.hdmi.7:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
> [pulseaudio] [pulseaudio] conf.c: function snd_func_refer returned error: No
> such file or directory
> [pulseaudio] [pulseaudio] conf.c: Evaluate error: No such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM hdmi:0,7
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hdmi:0,7: No
> such file or directory
> [pulseaudio] [pulseaudio] pcm.c: Unknown PCM dcahdmi:0,7
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:0,7:
> No such file or directory
> [pulseaudio] [pulseaudio] alsa-util.c: Error opening PCM device hw:0: No such
> file or directory
> [pulseaudio] [pulseaudio] module-card-restore.c: Restoring port latency
> offsets for card alsa_card.usb-QCM_Astro_HD_Camera-03.
> [pulseaudio] [pulseaudio] card.c: alsa_card.usb-QCM_Astro_HD_Camera-03:
> active_profile: input:analog-stereo
> [pulseaudio] [pulseaudio] card.c: Created 3 "alsa_card.usb-
> QCM_Astro_HD_Camera-03"
> [pulseaudio] [pulseaudio] alsa-util.c: Cannot disable ALSA period wakeups
> [pulseaudio] [pulseaudio] alsa-util.c: ALSA period wakeups were not disabled
> [pulseaudio] [pulseaudio] alsa-source.c: Successfully opened device front:0.
> [pulseaudio] [pulseaudio] alsa-source.c: Selected mapping 'Analog Stereo'
> (analog-stereo).
> [pulseaudio] [pulseaudio] alsa-source.c: Successfully enabled mmap() mode.
> [pulseaudio] [pulseaudio] alsa-source.c: Successfully enabled timer-based
> scheduling mode.
> [pulseaudio] [pulseaudio] control.c: Invalid CTL front:0
> [pulseaudio] [pulseaudio] alsa-util.c: Unable to attach to mixer front:0: No
> such file or directory
> [pulseaudio] [pulseaudio] alsa-util.c: Successfully attached to mixer 'hw:0'
> [pulseaudio] [pulseaudio] module-device-restore.c: Restoring port for source
> source:alsa_input.usb-QCM_Astro_HD_Camera-03.analog-stereo.
> [pulseaudio] [pulseaudio] module-device-restore.c: Restoring volume for source
> alsa_input.usb-QCM_Astro_HD_Camera-03.analog-stereo: front-left: 41481
> /  63%,   front-right: 41481 /  63%
> [pulseaudio] [pulseaudio] module-device-restore.c: Restoring mute state for
> source alsa_input.usb-QCM_Astro_HD_Camera-03.analog-stereo: muted
> [pulseaudio] [pulseaudio] source.c: Created source 3 "alsa_input.usb-
> QCM_Astro_HD_Camera-03.analog-stereo" with sample spec s16le 2ch 44100Hz and
> channel map front-left,front-right
> [pulseaudio] [pulseaudio] source.c:     alsa.resolution_bits = "16"
> [pulseaudio] [pulseaudio] source.c:     device.api = "alsa"
> [pulseaudio] [pulseaudio] source.c:     device.class = "sound"
> [pulseaudio] [pulseaudio] source.c:     alsa.class = "generic"
> [pulseaudio] [pulseaudio] source.c:     alsa.subclass = "generic-mix"
> [pulseaudio] [pulseaudio] source.c:     alsa.name = "USB Audio"
> [pulseaudio] [pulseaudio] source.c:     alsa.id = "USB Audio"
> [pulseaudio] [pulseaudio] source.c:     alsa.subdevice = "0"
> [pulseaudio] [pulseaudio] source.c:     alsa.subdevice_name = "subdevice #0"
> [pulseaudio] [pulseaudio] source.c:     alsa.device = "0"
> [pulseaudio] [pulseaudio] source.c:     alsa.card = "0"
> [pulseaudio] [pulseaudio] source.c:     alsa.card_name = "Astro HD Camera"
> [pulseaudio] [pulseaudio] source.c:     alsa.long_card_name = "QCM Astro HD
> Camera at usb-0000:00:14.0-7, high speed"
> [pulseaudio] [pulseaudio] source.c:     alsa.driver_name = "snd_usb_audio"
> [pulseaudio] [pulseaudio] source.c:     device.bus_path = "pci-0000:00:14.0-
> usb-0:7:1.3"
> [pulseaudio] [pulseaudio] source.c:     sysfs.path =
> "/devices/pci0000:00/0000:00:14.0/usb3/3-7/3-7:1.3/sound/card0"
> [pulseaudio] [pulseaudio] source.c:     udev.id = "usb-QCM_Astro_HD_Camera-03"
> [pulseaudio] [pulseaudio] source.c:     device.bus = "usb"
> [pulseaudio] [pulseaudio] source.c:     device.vendor.id = "0408"
> [pulseaudio] [pulseaudio] source.c:     device.vendor.name = "Quanta Computer,
> Inc."
> [pulseaudio] [pulseaudio] source.c:     device.product.id = "2090"
> [pulseaudio] [pulseaudio] source.c:     device.product.name = "Astro HD
> Camera"
> [pulseaudio] [pulseaudio] source.c:     device.serial = "QCM_Astro_HD_Camera"
> [pulseaudio] [pulseaudio] source.c:     device.form_factor = "webcam"
> [pulseaudio] [pulseaudio] source.c:     device.string = "front:0"
> [pulseaudio] [pulseaudio] source.c:     device.buffering.buffer_size =
> "352800"
> [pulseaudio] [pulseaudio] source.c:     device.buffering.fragment_size =
> "176400"
> [pulseaudio] [pulseaudio] source.c:     device.access_mode = "mmap+timer"
> [pulseaudio] [pulseaudio] source.c:     device.profile.name = "analog-stereo"
> [pulseaudio] [pulseaudio] source.c:     device.profile.description = "Analog
> Stereo"
> [pulseaudio] [pulseaudio] source.c:     device.description = "Astro HD Camera
> Analog Stereo"
> [pulseaudio] [pulseaudio] source.c:     alsa.mixer_name = "USB Mixer"
> [pulseaudio] [pulseaudio] source.c:     alsa.components = "USB0408:2090"
> [pulseaudio] [pulseaudio] source.c:     module-udev-detect.discovered = "1"
> [pulseaudio] [pulseaudio] source.c:     device.icon_name = "camera-web-usb"
> [pulseaudio] [pulseaudio] alsa-source.c: Using 2,0 fragments of size 176400
> bytes (1000,00ms), buffer size is 352800 bytes (2000,00ms)
> [pulseaudio] [pulseaudio] alsa-source.c: Time scheduling watermark is 20,00ms
> [pulseaudio] [pulseaudio] alsa-source.c: Successfully enabled deferred volume.
> [pulseaudio] [pulseaudio] alsa-source.c: Hardware volume ranges from -8,00 dB
> to 22,50 dB.
> [pulseaudio] [pulseaudio] alsa-source.c: Fixing base volume to -22,50 dB
> [pulseaudio] [pulseaudio] alsa-source.c: Using hardware volume control.
> Hardware dB scale supported.
> [pulseaudio] [pulseaudio] alsa-source.c: Using hardware mute control.
> [rtkit-daemon] Successfully made thread 27026 of process 26844 owned by '4728'
> RT at priority 5._
> [pulseaudio] [alsa-source-USB Audio] util.c: Successfully enabled SCHED_RR
> scheduling for thread, with priority 5.
> [pulseaudio] [alsa-source-USB Audio] alsa-source.c: Starting capture.
> [pulseaudio] [pulseaudio] module.c: Loaded "module-alsa-card" (index: #25;
> argument: "device_id="0" name="usb-QCM_Astro_HD_Camera-03"
> card_name="alsa_card.usb-QCM_Astro_HD_Camera-03" namereg_fail=false tsched=yes
> fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes
> avoid_resampling=no card_properties="module-udev-detect.discovered=1"").
> [pulseaudio] [pulseaudio] module-udev-detect.c: Card
> /devices/pci0000:00/0000:00:14.0/usb3/3-7/3-7:1.3/sound/card0 (alsa_card.usb-
> QCM_Astro_HD_Camera-03) module loaded.
> [pulseaudio] [pulseaudio] module-suspend-on-idle.c: Source alsa_input.usb-
> QCM_Astro_HD_Camera-03.analog-stereo idle for too long, suspending ...
> [pulseaudio] [alsa-source-USB Audio] alsa-source.c: Device suspended...
>
> # uname -r
> 5.6.12-gentoo
>
> Same on 5.7.4-gentoo.
>
> What can I do to solve it at boot without re-plugging the hardware?
>
> Just trying to rmmod and modrobe again does not solve the issue if not re-
> plugging the hardware:
>
> [kernel] uvcvideo: Found UVC 1.00 device Astro HD Camera (0408:2090)
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 2 on unit 1: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 3 on unit 1: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 4 on unit 1: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 6 on unit 1: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 11 on unit 1: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 13 on unit 1: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 8 on unit 1: -110
> (exp. 1).
> [pulseaudio] [pulseaudio] alsa-util.c: snd_pcm_hw_params failed: Connection
> timed out
> [kernel] usb 3-7: 4:1: cannot set freq 44100 to ep 0x84
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 2 on unit 2: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 3 on unit 2: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 6 on unit 2: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 7 on unit 2: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 8 on unit 2: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 9 on unit 2: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 10 on unit 2: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 1 on unit 2: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 5 on unit 2: -110
> (exp. 1).
> [kernel] uvcvideo: Failed to query (GET_INFO) UVC control 11 on unit 2: -110
> (exp. 1).
> [kernel] usb 3-7: 4:1: cannot set freq 44100 to ep 0x84
> [kernel] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling
> workaround.
> [kernel] usb 3-7: 4:1: cannot set freq 44100 to ep 0x84
>
>
> Best regards,
> Massimo

[linux-uvc-devel] Error Report: Generic UVC USB HD WebCam (1d6c:0102)

[Deven P. <dev...@gm...>]

I just received this today from Amazon. Tried to plug it in to my
Xubuntu laptops and a number of issues immediately arose.

1. The Bluetooth started acting up. Random disconnects on my bluetooth
mouse/headphones
2. Some apps would freeze
3. Shutting down/starting up hangs until I unplug the device

I searched and found a few archives from this list about
troubleshooting and enabling quirks modes. I tried a number of
different combinations, but I always had to blacklist `snd-usb-audio`
before anything would work. Here's a list of my attempts:

quirks=0x00000001 - Driver loads when device is plugged in, errors in
dmesg when attempting to use it
quirks=0x00000002- Driver loads, errors when accessed
quirks=0x00000004 - Driver loads and immediately has errors in dmesg
before accessing it
quirks=0x00000008 - Driver loads and immediately errors before using
quirks=0x00000010 - Driver loads and immediately errors before using
quirks=0x00000020 - Driver loads and immediately errors before using
quirks=0x00000080 - Driver loads, accessing device works initially,
trying to change settings in OBS causes freeze and errors in dmesg
quirks=0x00000100 - Driver loads, accessing device works initially,
trying to change settings in OBS causes freeze and errors in dmesg
quirks=0x00000200 - Driver loads, accessing device works initially,
trying to change settings in OBS causes freeze and errors in dmesg
quirks=0x00000300 - Driver loads, accessing device works initially,
trying to change settings in OBS causes freeze and errors in dmesg

quirks=0x00000101 - Driver loads, errors when accessed
quirks=0x00000102 - Driver loads, errors when accessed
quirks=0x00000103 - Driver loads, errors when accessed
quirks=0x00000203 - Driver loads, errors when accessed
quirks=0x00000206 - Driver loads, video works initially, trying to
change settings in OBS causes freeze and errors in dmesg and color
problems in video, eventually freezes

When the video DID display (for short periods) it was oversaturated
and looked "fuzzy".

When running `lsusb -d 1d6c:0103 -v` I often got the error:

can't get debug descriptor: Resource temporarily unavailable
cannot read device status, Resource temporarily unavailable (11)

I'm planning to return the device, but I can hold on to it for a few
days if that is helpful to debug/diagnose.

[linux-uvc-devel] Lihappe8 Webcam errors but works

[David A. <da...@li...>]

Lihappe8 Webcan L69SN 1080P
Sonix Technology Co
0c46:636b

Using
Ubuntu 18.04.4 LTS

In spite of the following errors, it seems to work.

[221040.883494] usb 3-6.2: new high-speed USB device number 7 using xhci_hcd
[221041.042148] usb 3-6.2: New USB device found, idVendor=0c46, idProduct=636b
[221041.042153] usb 3-6.2: New USB device strings: Mfr=2, Product=1, SerialNumber=3
[221041.042157] usb 3-6.2: Product: Lihappe8 Webcam L69SN 1080P
[221041.042160] usb 3-6.2: Manufacturer: Sonix Technology Co., Ltd.
[221041.042162] usb 3-6.2: SerialNumber: SN0001
[221041.068518] media: Linux media interface: v0.10
[221041.077848] usb 3-6.2: 3:1: cannot get freq at ep 0x84
[221041.081396] usbcore: registered new interface driver snd-usb-audio
[221041.085432] Linux video capture interface: v2.00
[221041.098748] uvcvideo: Found UVC 1.00 device Lihappe8 Webcam L69SN 1080P (0c46:636b)
[221041.109492] uvcvideo 3-6.2:1.0: Entity type for entity Extension 3 was not initialized!
[221041.109493] uvcvideo 3-6.2:1.0: Entity type for entity Processing 2 was not initialized!
[221041.109494] uvcvideo 3-6.2:1.0: Entity type for entity Camera 1 was not initialized!
[221041.109644] input: Lihappe8 Webcam L69SN 1080P: Li as /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6.2/3-6.2:1.0/input/input16
[221041.109751] usbcore: registered new interface driver uvcvideo
[221041.109752] USB Video Class driver (1.1.1)
[221041.131691] usb 3-6.2: 3:1: cannot get freq at ep 0x84
[221041.147718] usb 3-6.2: 3:1: cannot get freq at ep 0x84

Tried on Ubuntu 20.04 machine with different error text, but again it seemed to wor
in spite of the errors.

[linux-uvc-devel] Wimius 4k Q1 Camera

[Matteo C. <mat...@gm...>]

Hi there,

I was trying to connect my Action Cam (Wimius 4k Q1) to various Linux
distros (mainly Ubuntu and Raspbian) yet it seems the camera / produced is
not yet supported (based on this list http://www.ideasonboard.org/uvc/)

I've already tried a couple of thing but no luck.
The infos I've gathered until now are:

When connected and running "*lsusb*" I get

*Bus 001 Device 011: ID 1f3a:1002 Onda (unverified)*

And running *lsusb -d 1f3a:1002 -v | grep "14 Video"*

Does not report anything (if this is helpful in any way).

I'm available to provide any info you may need in order to support it!

Thanks!