On Mon, 8 Oct 2018, Christoph Groth wrote: > On Sun, 7 Oct 2018, Alan Stern wrote: > > > On Fri, 5 Oct 2018, Christoph Groth wrote: > > > > > I would be grateful for hints on how solve or further debug this > > > problem. > > > > A good start would be to post a usbmon trace showing what happens when > > you plug in the Garmin device. Also you could post the dmesg log, > > because it might contain some useful information about what happened > > during the failure. > > Thanks, Alan. Here are two sets of logs: > > * x220: The device freezes. Taken on a ThinkPad X220 (running > 4.17.0-3-amd64 #1 SMP Debian 4.17.17-1 (2018-08-18) x86_64 GNU/Linux) > > * cubie: The device works. Taken on a Cubieboard2 (running > 4.9.0-6-armmp-lpae #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) armv7l > GNU/Linux) > > The usbmon logs should contain lines only from the device in question. > In x220.usbmon.gz, I marked the point where output ceases before the > device is unplugged. The difference between the two usbmon traces is this request in the x220 trace: ffff9d69e4b579c0 293665112 S Ci:1:018:0 s 80 06 03ee 0000 0400 1024 < ffff9d69e4b579c0 294668236 C Ci:1:018:0 -2 0 This is a Get-String-Descriptor request for string index 0xee, which is reserved by Microsoft as their OS String Descriptor. Evidently the Garmin does not like this request, because it freezes up and the request has to be cancelled. After that the Garmin doesn't do anything, whereas by contrast on the cubie it disconnects after about 4 seconds and then reconnects with a different set of descriptors (those of a proper mass-storage device). As far as I know the kernel does not send this request for the OS String Descriptor automatically, so most likely it comes from some program running on the x220 and not on the cubie. One good candidate is usb_modeswitch, but it could be something else. You might get more information in the kernel log if you turn on the usbfs_snoop module parameter for the usbcore module. Alan Stern
