There is nothing orderly about the whole mode-switching business. From the system's view it's no different than a physical unplug and reinsert of a device. The word "API" does not come to my mind at all.
For usb_modeswitch as such, timing is not important - in theory. The tipping point *should* be the driver detachement that is done by libusb. In my simple thinking, I expect to have full control over the device from then on. I can obviously send and receive data and control messages. So how can the system keep a hold of the device? There is one more idea to check. What if the system is grabbing the device again *after* the switching message was issued and the device handle is released? Can it be that the 3.0 driver is just so fast (or "clever") that it re-owns the device immediately? To test this, there is a parameter called "ReleaseDelay" that will cause usb_modeswitch to hold the device under its control for any number of milliseconds. One modem family (BandLuxe) actually requires this to complete the mode switch. BTW, I just tried my whole modem collection (9 sticks!) on Ubuntu 12.04 x64, up to date, in the only USB 3.0 port that I have. Neither a delay_use of "1" nor one of "0" caused any disruption at all. So I'm still sure there is some hardware involved in this. See the xHCI errors in the logs above, even when using the standard "eject" tool. Unfortunately, this means that I have no way to help with testing ... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/979697 Title: Modeswitching modem not working with some USB 3.0 host controllers To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/979697/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
