On Tue, 2020-05-26 at 12:14 +0200, Oliver Neukum wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > Am Dienstag, den 26.05.2020, 08:59 +0000 schrieb Joakim Tjernlund: > > On Tue, 2020-05-26 at 10:47 +0200, Oliver Neukum wrote: > > > Am Montag, den 25.05.2020, 16:49 +0000 schrieb Joakim Tjernlund: > > > > > > > To be clear, I can pull the cable and put it back and there are no garbage chars. > > > > There is also this error: > > > > [Wed May 20 14:03:25 2020] cdc_acm 1-6.3:1.1: acm_ctrl_irq - usb_submit_urb failed: -19 > > > > [Wed May 20 14:03:25 2020] usb 1-6-port2: attempt power cycle > > > > [Wed May 20 14:03:26 2020] usb 1-6.3: USB disconnect, device number 86 > > > > [Wed May 20 14:03:26 2020] cdc_acm 1-6.3:1.1: failed to set dtr/rts > > > > > > > > Should not this auto reenable emulate reattaching the USB cable? > > > > > > Hi, > > > > > > yes it should. You find the garage characters after the EMI event. How > > > sure are you that they arrive after the event and not during the event? > > > > > > > Don't known how to determine that? > > I can say that > > acm_ctrl_irq - usb_submit_urb failed: -19 > > -19 is -ENODEV > > The driver thinks tries to resubmit the URB asking for control > messages. > Basically you are seeing error handling starting and failing due > to a subsequent disconnect. > > > and > > cdc_acm 1-6.3:1.1: failed to set dtr/rts > > are unique to this EMI event though. It does not feel like this > > reenabling follow the same procedure as a cable pull? > > As I can only see the above two errors I think we should get rid of > > these first. > > The timing is different and if there is EMI transfer can end > in errors and cause error handling to kick in. You are seeing > symptoms. You can try enabling dynamic debugging to get > a better log. > > Regards > Oliver > Tried som dynamic debug for module cdc_acm got something I cannot parse: [Tue May 26 18:24:30 2020] cdc_acm 1-6.3:1.1: ttyACM0: USB ACM device [Tue May 26 18:24:30 2020] cdc_acm 1-6.3:1.1: acm_ctrl_msg - rq 0x20, val 0x0, len 0x7, result 7 [Tue May 26 18:24:43 2020] usb 1-6.2: new high-speed USB device number 36 using xhci_hcd [Tue May 26 18:24:43 2020] cdc_ether 1-6.2:1.0 usb0: register 'cdc_ether' at usb-0000:00:14.0-6.2, CDC Ethernet Device, 92:d1:c9:b4:91:d5 [Tue May 26 18:24:43 2020] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready [Tue May 26 18:25:40 2020] cdc_acm 1-6.3:1.1: acm_ctrl_msg - rq 0x22, val 0x3, len 0x0, result 0 [Tue May 26 18:25:40 2020] cdc_acm 1-6.3:1.1: acm_tty_set_termios - set line: 115200 0 0 8 [Tue May 26 18:25:40 2020] cdc_acm 1-6.3:1.1: acm_ctrl_msg - rq 0x20, val 0x0, len 0x7, result 7 [Tue May 26 18:25:42 2020] cdc_acm 1-6.3:1.1: acm_ctrl_irq - urb shutting down with status: -2 [Tue May 26 18:25:42 2020] cdc_acm 1-6.3:1.2: acm_read_bulk_callback - urb shutting down with status: -2 .... I do note one thing in: First connect after power on for the gadget I see some garbage chars when connecting with cu. However, if I just do a "cat /dev/ttyACM0", Ctrl-C and then cu I there are no garbage chars. It feels like the gadget is spewing some garbage at power on and this gets saved in hosts cdc_acm, once I open /dev/ttyACM0 for write, these gets echoed back to the gadget. If so, cdc_acm fails to clear its buffers before the first open, does this make sense to you? Jocke
