On Tue, 2020-05-26 at 18:46 +0200, Joakim Tjernlund wrote: > 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? > Got some evidence now, I change the default baud rate form 9600 to 115200 in cdc_acm and now I can see(instead of garbage chars): cu usbacm0 Connected. ^@ U-Boot SPL This "u-boot SPL" is the first thing u-boot writes and somehow this is remembered, I assume, by cdc_acm and gets echoed back when I open ttyACM0 Jocke
