Re: ttyACM: disabled by hub (EMI?), re-enabling... Causes garbage chars & disconnect

[Oliver Neukum <oneukum@suse.com>]

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