On Mon, May 02, 2022 at 03:54:34PM +0200, Martin Kepplinger wrote: > Am Freitag, dem 29.04.2022 um 16:21 -0400 schrieb Alan Stern: > > I don't see why re-initialization works any better. It's not likely > > to > > be a question of waiting long enough, since you already waited for 5 > > seconds. There must be something different between the reset-resume > > and > > the re-initialization, but I can't tell what. > > Thanks for this great analysis and clarifications! It really looks like > that difference is what I want to find. > > > > > Maybe a usbmon trace showing the entire thing, both the reset-resume > > and > > the following re-initialization, would help. > > > > I append that here. A recording of the whole syslog until the modem is > re-enumerated and working again. And the usbmon recording. I added a > few usbmon timestampts to the kernel log to be able to correlate the 2 > a bit easier. The usbmon trace shows that quite a lot happens during re-enumeration that doesn't happen during the reset-resume. No doubt the reason for this is that the cdc-wdm driver doesn't have a real reset-resume handler; the operations it carries out for a reset-resume are the same as for a normal resume, and that clearly is not appropriate here. For example, the usbmon trace shows that the kernel sends a Set-Interface request to the modem during re-enumeration and then does a whole lot of probing that I don't understand. None of this stuff happens during the reset-resume. Probably the modem decides that without any of this extra configuration, it doesn't need to do anything -- and that's why it disconnects itself. So the person you need to talk to is the maintainer of the USB CDC drivers, Oliver Neukum (CC'ed). Alan Stern