On 26 September 2017 at 06:28, Alan Stern <[email protected]> wrote:
>
> On Mon, 25 Sep 2017, David Tulloh wrote:
>
> > Hi,
> >
> > I have been trying to get a UVC gadget running through configfs and
> > wired in to dummy_hcd.
> > ...
>
> Does uvc use isochronous transfers? I assume it would, since it's a
> video protocol.
>
> dummy-hcd does not support isochronous. I don't know what would happen
> if you tried it, but one way or another it would not work the way you
> want.
>
> Of course, you might be facing a different problem.
>
> Alan Stern
Thanks Alan,
I was facing a different problem but your suggestion put me on the right path.
Sorry it took me so long to update the thread, it has taken me a while
to get a basic understanding of the debugging tools and processes
built into the kernel.
My issue was the rare beast, a consistently repeatable lock contention.
The wonderful LOCK_DEP output summarises it better than I could.
Unfortunately I don't understand the locking requirements nearly well
enough to craft a patch.
Now I have solved this issue (turn off SMP) I'm looking forward to see
if the isochronous problem bites me too.
David
[ 88.361471] ============================================
[ 88.362014] WARNING: possible recursive locking detected
[ 88.362580] 4.14.0-rc2+ #9 Not tainted
[ 88.363010] --------------------------------------------
[ 88.363561] v4l_id/526 is trying to acquire lock:
[ 88.364062] (&(&cdev->lock)->rlock){....}, at:
[<ffffffffa0547e03>] composite_disconnect+0x43/0x100 [libcomposite]
[ 88.365051]
[ 88.365051] but task is already holding lock:
[ 88.365826] (&(&cdev->lock)->rlock){....}, at:
[<ffffffffa0547b09>] usb_function_deactivate+0x29/0x80 [libcomposite]
[ 88.366858]
[ 88.366858] other info that might help us debug this:
[ 88.368301] Possible unsafe locking scenario:
[ 88.368301]
[ 88.369304] CPU0
[ 88.369701] ----
[ 88.370101] lock(&(&cdev->lock)->rlock);
[ 88.370623] lock(&(&cdev->lock)->rlock);
[ 88.371145]
[ 88.371145] *** DEADLOCK ***
[ 88.371145]
[ 88.372211] May be due to missing lock nesting notation
[ 88.372211]
[ 88.373191] 2 locks held by v4l_id/526:
[ 88.373715] #0: (&(&cdev->lock)->rlock){....}, at:
[<ffffffffa0547b09>] usb_function_deactivate+0x29/0x80 [libcomposite]
[ 88.374814] #1: (&(&dum_hcd->dum->lock)->rlock){....}, at:
[<ffffffffa05bd48d>] dummy_pullup+0x7d/0xf0 [dummy_hcd]
[ 88.376289]
[ 88.376289] stack backtrace:
[ 88.377726] CPU: 0 PID: 526 Comm: v4l_id Not tainted 4.14.0-rc2+ #9
[ 88.378557] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.10.2-1 04/01/2014
[ 88.379504] Call Trace:
[ 88.380019] dump_stack+0x86/0xc7
[ 88.380605] __lock_acquire+0x841/0x1120
[ 88.381252] lock_acquire+0xd5/0x1c0
[ 88.381865] ? composite_disconnect+0x43/0x100 [libcomposite]
[ 88.382668] _raw_spin_lock_irqsave+0x40/0x54
[ 88.383357] ? composite_disconnect+0x43/0x100 [libcomposite]
[ 88.384290] composite_disconnect+0x43/0x100 [libcomposite]
[ 88.385490] set_link_state+0x2d4/0x3c0 [dummy_hcd]
[ 88.386436] dummy_pullup+0xa7/0xf0 [dummy_hcd]
[ 88.387195] usb_gadget_disconnect+0xd8/0x160 [udc_core]
[ 88.387990] usb_gadget_deactivate+0xd3/0x160 [udc_core]
[ 88.388793] usb_function_deactivate+0x64/0x80 [libcomposite]
[ 88.389628] uvc_function_disconnect+0x1e/0x40 [usb_f_uvc]
[ 88.390445] uvc_v4l2_release+0x33/0x90 [usb_f_uvc]
[ 88.391224] v4l2_release+0x38/0x80 [videodev]
[ 88.392003] __fput+0xed/0x230
[ 88.392776] ____fput+0xe/0x10
[ 88.393515] task_work_run+0x85/0xb0
[ 88.394286] exit_to_usermode_loop+0xce/0xd0
[ 88.395066] do_syscall_64+0x128/0x1a0
[ 88.395775] entry_SYSCALL64_slow_path+0x25/0x25
[ 88.396534] RIP: 0033:0x7ff57e33b250
[ 88.397217] RSP: 002b:00007ffd1590d6e8 EFLAGS: 00000246 ORIG_RAX:
0000000000000003
[ 88.398187] RAX: 0000000000000000 RBX: 0000000000000003 RCX: 00007ff57e33b250
[ 88.399113] RDX: 000000000000000a RSI: 00007ff57e327760 RDI: 0000000000000003
[ 88.400035] RBP: 00007ff57e969698 R08: 00007ff57e327760 R09: 00007ff57e969700
[ 88.401154] R10: 000055d4a53e3ecc R11: 0000000000000246 R12: 0000000000000000
[ 88.402518] R13: 00007ffd1590d870 R14: 0000000000000000 R15: 0000000000000000
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html