Good morning On 08/12/2022 06:11, Felipe Balbi wrote:
Hi, Dan Scally <dan.scally@xxxxxxxxxxxxxxxx> writes:I'm having an issue with DWC3 which I'm hoping you might be able to shed light on. I'm using the UVC gadget function to stream video from an imx8mp platform, which works just fine. Once I have stopped streaming however and after some time has passed (the exact duration seems to vary quite a lot from 1-2 minutes to 15+ mins) I get a kernel warning like so:As Greg mentioned, please add Thinh, the new maintainer, to the loop.
Apologies to both of you; for some reason I thought you had taken over from Thinh rather than the other way around. Thanks for the heads up Greg.
[ 737.996842] configfs-gadget gadget.0: uvc: uvc_function_disable() [ 738.519582] configfs-gadget gadget.0: uvc: uvc_function_set_alt(0, 0) [ 738.526060] configfs-gadget gadget.0: uvc: reset UVC interrupt endpoint [ 738.532713] ------------[ cut here ]------------ [ 738.537683] dwc3 38100000.usb: No resource for ep1in [ 738.542712] WARNING: CPU: 0 PID: 645 at drivers/usb/dwc3/gadget.c:384 dwc3_send_gadget_ep_cmd+0x478/0x580 [ 738.552314] Modules linked in: [ 738.555402] CPU: 0 PID: 645 Comm: irq/208-dwc3 Not tainted 5.19.0-00034-gf017ce943b32 #82 [ 738.563601] Hardware name: Polyhex Debix Model A i.MX8MPlus board (DT) [ 738.570145] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 738.577128] pc : dwc3_send_gadget_ep_cmd+0x478/0x580 [ 738.582116] lr : dwc3_send_gadget_ep_cmd+0x478/0x580 [ 738.587102] sp : ffffffc00c3c39e0 [ 738.590433] x29: ffffffc00c3c39e0 x28: 0000000000031006 x27: 00000000ffffffea [ 738.597618] x26: 0000000000000006 x25: ffffff8004f32880 x24: ffffffc00c3c3abc [ 738.604801] x23: 0000000000000406 x22: ffffffffffff3f00 x21: ffffffffffff3f0c [ 738.611984] x20: ffffff8003872600 x19: 0000000000000001 x18: ffffffffffffffff [ 738.619166] x17: 000000000000001c x16: 00000000c99c42a5 x15: ffffffc08c3c36b7 [ 738.626347] x14: 0000000000000000 x13: 6e6931706520726f x12: 6620656372756f73 [ 738.633528] x11: 00000000000c02a7 x10: ffffffc009af1ac0 x9 : ffffffc0080c42bc [ 738.640710] x8 : 00000000ffffefff x7 : ffffffc009af1ac0 x6 : 0000000000000000 [ 738.647891] x5 : ffffff807fb2eb08 x4 : 0000000000000000 x3 : 0000000000000027 [ 738.655072] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff80158a8000 [ 738.662255] Call trace: [ 738.664721] dwc3_send_gadget_ep_cmd+0x478/0x580 [ 738.669362] __dwc3_gadget_ep_enable+0x4f4/0x714 [ 738.674004] dwc3_gadget_ep_enable+0x6c/0x15c [ 738.678382] usb_ep_enable+0x4c/0x1bc [ 738.682067] uvc_function_set_alt+0xcc/0x264 [ 738.686362] composite_setup+0x7ec/0x195c [ 738.690395] configfs_composite_setup+0x90/0xc0 [ 738.694950] dwc3_ep0_interrupt+0x834/0x9e0 [ 738.699156] dwc3_thread_interrupt+0x994/0xd70 [ 738.703624] irq_thread_fn+0x38/0xa4 [ 738.707221] irq_thread+0x184/0x230 [ 738.710733] kthread+0x118/0x120 [ 738.713981] ret_from_fork+0x10/0x20 [ 738.717582] irq event stamp: 41021 [ 738.720998] hardirqs last enabled at (41019): [<ffffffc008082858>] finish_task_switch.isra.0+0xe8/0x264 [ 738.730501] hardirqs last disabled at (41021): [<ffffffc008f15058>] _raw_spin_lock_irqsave+0xc4/0x170 [ 738.739747] softirqs last enabled at (41014): [<ffffffc008a25b90>] dwc3_thread_interrupt+0x1c0/0xd70 [ 738.748988] softirqs last disabled at (41020): [<ffffffc008a259dc>] dwc3_thread_interrupt+0xc/0xd70 ep1in in this instance refers to a Status Interrupt Endpoint under the UVC specification, which is being "reset" by uvc_function_set_alt() against the VideoControl interface (meaning a call to usb_ep_disable() followed by usb_ep_enable(), see [1]). The isochronous endpoint that data is streamed across is treated similarly in the same function (when called for the VideoStreaming interface) and never seems to show the same warning and as far as I can tell the operation ought to be safe, so I'm struggling to see anything in the f_uvc code that's misbehaving to cause the problem. I wondered if you might be able to take a look at the trace and regdump of the dwc3 (which was taken immediately after the warning is thrown) and see if that sheds any light on what might be going on?Best way forward is to collect dwc3 trace points, so we can see what the HW is doing. For details, see [1]. [1] https://kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs
Both the trace and regdump should be in the attached .tar.gz
Attachment:
dwc3.tar.gz
Description: application/gzip
