On 26 September 2017 at 06:28, Alan Stern <st...@rowland.harvard.edu> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to