Hi, Ferry Toth <fntoth@xxxxxxxxx> writes: >>>> Ferry Toth <fntoth@xxxxxxxxx> writes: >>>>> Op 27-10-2020 om 22:16 schreef Andy Shevchenko: >>>>>> On Tue, Oct 27, 2020 at 10:13 PM Ferry Toth <fntoth@xxxxxxxxx> wrote: >>>>>>> Op 22-10-2020 om 15:43 schreef Andy Shevchenko: >>>>>>>> On Thu, Oct 22, 2020 at 4:21 PM Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> wrote: >>>>>>>>> Ferry Toth wrote: >>>>>> ... >>>>>> >>>>>>>>> There are some fixes to dwc3 in kernel mainline. Is it possible to test >>>>>>>>> this against linux-next? >>>>>>>> I think the best is to wait for v5.10-rc1 and retest. >>>>>> Can you give a try of v5.10-rc1? >>>>> Yes, I just tried: >>>>> >>>>> I booted in host mode, then flip the switch. Gadget come up, go down >>>>> once, then come up again and stay up. >>>> please collect trace events. It's important to figure out why it's going >>>> down, even if only once. Make sure to collect trace *and* dmesg so we >>>> can correlate trace with the reenumeration that should show up in dmesg. >>>> >>>> thanks >>> Sorry, I had to replace mobo. Now back on this. >>> >>> As is, on Edison I can record with something like "perf record -e >>> 'dwc3:dwc3_gadget*' -e 'gadget:*' -g -a". >>> Then get the trace buffer with "perf script > gadget.txt". Then at each >>> trace point we get a stack trace like: >>> >>> file-storage 831 [001] 4445.240038: dwc3:dwc3_gadget_ep_cmd: [FAILED >>> TO PARSE] name=ep4in cmd=524295 param0=0 param1=0 param2=0 cmd_status=0 >>> ffffffff9a35b7e7 __traceiter_dwc3_gadget_ep_cmd+0x37 >>> ([kernel.kallsyms]) >>> ffffffff9a35b7e7 __traceiter_dwc3_gadget_ep_cmd+0x37 >>> ([kernel.kallsyms]) >>> ffffffff9a35fa40 dwc3_send_gadget_ep_cmd+0x320 ([kernel.kallsyms]) >>> ffffffff9a3606d0 __dwc3_gadget_kick_transfer+0x200 ([kernel.kallsyms]) >>> ffffffff9a361114 dwc3_gadget_ep_queue+0xe4 ([kernel.kallsyms]) >>> ffffffff9a3afc3a usb_ep_queue+0x2a ([kernel.kallsyms]) >>> ffffffffc047c301 start_transfer.isra.0+0x21 ([kernel.kallsyms]) >>> ffffffffc047c88a start_in_transfer.isra.0+0x3a ([kernel.kallsyms]) >>> ffffffffc047c93d send_status+0x8d ([kernel.kallsyms]) >>> ffffffffc047dd05 fsg_main_thread+0x3c5 ([kernel.kallsyms]) >>> ffffffff99c853b9 kthread+0xf9 ([kernel.kallsyms]) >>> ffffffff99c01a32 ret_from_fork+0x22 ([kernel.kallsyms]) >>> >>> "perf list" shows the tracepoint events, the same as under >>> /sys/kernel/debug/tracing/events/ >>> >>> Question is which points to trace (above command fills buffer to 35MB in >>> 10sec). Do you have suggestions? >> don't enable any gadget event. Only dwc3 events. Also, enable *all* dwc3 >> events. Usually, I avoid perf when doing this and just go straight to >> /sys/kernel/trace/. > Ok, I can do that. But I'm not sure how I turn on tracing and capture > the results. Got you covered ;-) https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs -- balbi
Attachment:
signature.asc
Description: PGP signature
