On Tue, 9 Oct 2018, Christoph Groth wrote: > On Tue, 9 Oct 2018, Alan Stern wrote: > > > 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: > > > > > > (...) > > > > 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). > > Thanks! So, in a nutshell, this is another bug in the Foretrex > firmware? So it appears. > They make really nice hardware, but why don't they realize > that abandoning their totally closed firmware development model would > actually profit them? The same could be asked about a lot of companies. :-( > > 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. > > Uninstalling usb_modeswitch didn't help, so I enabled usbfs_snoop and > saw in dmesg that the command mtp-probe is launched when the device is > plugged in. Uninstalling this one did the trick, but it also means that > I can no longer transfer files to and from Android phones. (Perhaps > there's a way to inhibit mtp-probe only for the Garmin device.) That should be possible, expecially if it gets triggered by a udev rule. > One last question: is the 'lsusb -v' freeze that I observed anything > that should be reported? Or is it just fair for lsusb to block upon > waiting for a device that froze? IIRC, I wasn't even able to 'kill -9' > it, but eventually it went away. Most likely the lsusb freeze was simply the result of various USB requests timing out, since presumably the Garmin doesn't respond to any of them once it has been messed up. If you want to pursue this, you could collect a usbmon trace showing the plug-in and the "lsusb -v" freeze. Alan Stern
