[Gigabyte T1005] Modeswitching modem not working

Marking as upstream as I currently use the same version as the latest upstream 1.2.3.

The only thing sticking out is the somewhat "non-mainstream" message content. No other (ZTE) device is using this.

I'd suggest trying with the mainstream ZTE command (basically an EJECT):

- Extract the "19d2:0166" file from /usr/share/usb_modeswitch/configPack.tar.gz

- Put it into /etc/usb_modeswitch.d and edit it

- Replace the existing MessageContent line with these:

MessageContent="5553424312345678000000000000061e000000000000000000000000000000"
MessageContent2="5553424312345679000000000000061b000000020000000000000000000000"

Josua: using that switch message, it does not even switch in the USB 2.0 port.

Maybe there is a slightly different way to access USB 2.0 devices in a USB 3.0 port? Or a bug in libusb or the kernel driver.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 979697

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Re-addressing this issue after a busy while.

Your usb_modeswitch log from a successful switch is indicating that your installation is using "libusb 0". This follows from the fact that the name of the bound driver ("usb-storage") is reported. "libusb 1" is not able to do this.

Can you try to compile the core binary of usb_modeswitch with "libusb1-compat0-dev" instead?
I'm not sure how it's exact name is on your system. It is a wrapper library to compile programs written for libusb0 with libusb1, without requiring any changes. It should replace "libusb0-dev".

Hmm, I see no compat package in Ubuntu, just:

libusb-0.1-4
libusb-1.0-0

$ ldd /usr/sbin/usb_modeswitch
 linux-gate.so.1 => (0xb779e000)
 libusb-0.1.so.4 => /lib/i386-linux-gnu/libusb-0.1.so.4 (0xb7773000)
 libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75ce000)
 /lib/ld-linux.so.2 (0xb779f000)

Is it not possible to build it with 1.0.x?

It is possible to build with libusb-1 - if you have libusb-compat-0.1 ...

Don't know why Ubuntu does not have it.
For specifics see:

http://libusb.org/

I opened bug #991004 to have the compat package in Ubuntu. Then installed it manually as described there. Now I have:

$ ldd /usr/sbin/usb_modeswitch
 linux-gate.so.1 => (0xb7769000)
 libusb-0.1.so.4 => /usr/local/lib/libusb-0.1.so.4 (0xb7742000)
 libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb759d000)
 libusb-1.0.so.0 => /lib/i386-linux-gnu/libusb-1.0.so.0 (0xb758c000)
 /lib/ld-linux.so.2 (0xb776a000)
 librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb7583000)
 libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7568000)

so the compat version in /usr/local/lib is used, but it still fails:

USB description data (for identification)
-------------------------
Manufacturer: ZTE,Incorporated
     Product: ZTE LTE Technologies MSM
  Serial No.: MF820DFFFS111111
-------------------------
Looking for active driver ...
 OK, driver found; name unknown, limitation of libusb1
 OK, driver "unkown" detached
Setting up communication with interface 0
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
 OK, message successfully sent
Resetting response endpoint 0x81
Resetting message endpoint 0x01

  searching devices, found USB ID 19d2:0166
   found matching vendor ID
  searching devices, found USB ID 1d6b:0003
 No new devices in target mode or class found

Plugging it into a USB 2.0 port still works with the compat lib:

Mode switching was successful, found 19d2:0167 (ZTE,Incorporated: ZTE LTE Technologies MSM)

I have encountered several cases lately where timing issues surfaced. I'm wondering if this may be connected to the spreading of 3.0 ports.

If you want to test, add the "WaitBefore=<n>" parameter to your custom config file. The value is in seconds - I'd start with 8 or so, decreasing it in case of success.

Unfortunately that did not help either, even with "config: WaitBefore set to 20". But it might be a tip to improve stability of the use of the modem in other USB ports.

You might try the "ResetUSB=1" parameter. This will issue a reset command after completing the message transfer.
Somewhat unsubtle and just a shot in the dark, but who knows?

I just hope we did not encounter an issue with the xhci driver ...

Did not help, but it seems there in fact are some error messages from xhci in the log:

[22280.520201] usb 6-2: new high-speed USB device number 10 using xhci_hcd
[22280.543397] usb 6-2: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes
[22280.543425] usb 6-2: ep 0x81 - rounding interval to 32768 microframes, ep desc says 0 microframes
[22280.550232] scsi21 : usb-storage 6-2:1.0
[22281.556563] scsi 21:0:0:0: CD-ROM ZTE USB SCSI CD-ROM 2.31 PQ: 0 ANSI: 0
[22281.565822] sr0: scsi-1 drive
[22281.572842] sr 21:0:0:0: Attached scsi CD-ROM sr0
[22281.574734] sr 21:0:0:0: Attached scsi generic sg1 type 5
[22333.104578] usb 6-2: reset high-speed USB device number 10 using xhci_hcd
[22353.104108] xhci_hcd 0000:02:00.0: Timeout while waiting for address device command
[22373.308119] xhci_hcd 0000:02:00.0: Timeout while waiting for address device command
[22373.512102] usb 6-2: device not accepting address 10, error -62
[22373.624219] usb 6-2: reset high-speed USB device number 10 using xhci_hcd
[22373.624241] usb 6-2: Device not responding to set address.
[22373.828115] usb 6-2: Device not responding to set address.
[22374.032131] usb 6-2: device not accepting address 10, error -71
[22374.144224] usb 6-2: reset high-speed USB device number 10 using xhci_hcd
[22374.144243] usb 6-2: Device not responding to set address.
[22374.348217] usb 6-2: Device not responding to set address.
[22374.552138] usb 6-2: device not accepting address 10, error -71
[22374.664207] usb 6-2: reset high-speed USB device number 10 using xhci_hcd
[22374.664226] usb 6-2: Device not responding to set address.
[22374.868113] usb 6-2: Device not responding to set address.
[22375.072140] usb 6-2: device not accepting address 10, error -71
[22375.072264] usb 6-2: USB disconnect, device number 10
[22375.072339] sr 21:0:0:0: Device offlined - not ready after error recovery
[22375.076860] xhci_hcd 0000:02:00.0: xHCI xhci_drop_endpoint called with disabled ep dcfda5a0
[22375.076881] xhci_hcd 0000:02:00.0: xHCI xhci_drop_endpoint called with disabled ep dcfda5cc
[22375.077490] xhci_hcd 0000:02:00.0: Bad Slot ID 1
[22375.077505] xhci_hcd 0000:02:00.0: Could not allocate xHCI USB device data structures
[22375.077527] hub 6-0:1.0: couldn't allocate port 2 usb_device
[22420.076166] usb 6-2: new high-speed USB device number 11 using xhci_hcd
[22420.076184] xhci_hcd 0000:02:00.0: ERROR: unexpected command completion code 0x0.
[22420.302753] usb 6-2: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes
[22420.302781] usb 6-2: ep 0x81 - rounding interval to 32768 microframes, ep desc says 0 microframes
[22420.305595] scsi22 : usb-storage 6-2:1.0
[22421.306184] scsi 22:0:0:0: CD-ROM ZTE USB SCSI CD-ROM 2.31 PQ: 0 ANSI: 0
[22421.314734] sr0: scsi-1 drive
[22421.315900] sr 22:0:0:0: Attached scsi CD-ROM sr0
[22421.320876] sr 22:0:0:0: Attached scsi generic sg1 type 5
[22428.280656] usb 6-2: reset high-speed USB device number 11 using xhci_hcd
[22428.299201] xhci_hcd 0000:02:00.0: xHCI xhci_drop_endpoint called with disabled ep f1d9d840
[22428.299217] xhci_hcd 0000:02:00.0: xHCI xhci_drop_endpoint called with disabled e...

Did you try the "eject" tool yet when on the 3.0 port?

# eject /dev/sr0

Is there a difference in the "dmesg" output if you plug into the 2.0 port?

May 2 12:05:15 marius-T1005 kernel: [18791.997154] xhci_hcd 0000:02:00.0: ERROR Transfer event TRB DMA ptr not part of current TD
May 2 12:05:31 marius-T1005 kernel: [18807.996898] sr 4:0:0:0: Device offlined - not ready after error recovery
May 2 12:05:41 marius-T1005 udevd[9591]: timeout 'cdrom_id --lock-media /dev/sr0'
May 2 12:05:42 marius-T1005 udevd[9591]: timeout: killing 'cdrom_id --lock-media /dev/sr0' [17485]
May 2 12:06:13 udevd[9591]: last message repeated 31 times
May 2 12:06:23 udevd[9591]: last message repeated 10 times
May 2 12:06:23 marius-T1005 kernel: [18859.997078] sr 4:0:0:0: Device offlined - not ready after error recovery
May 2 12:06:23 marius-T1005 kernel: [18860.000567] xhci_hcd 0000:02:00.0: ERROR Transfer event TRB DMA ptr not part of current TD
May 2 12:06:24 marius-T1005 udevd[9591]: timeout: killing 'cdrom_id --lock-media /dev/sr0' [17485]
May 2 12:07:15 udevd[9591]: last message repeated 51 times
May 2 12:07:15 marius-T1005 kernel: [18911.997026] sr 4:0:0:0: Device offlined - not ready after error recovery
May 2 12:07:16 marius-T1005 udevd[9591]: timeout: killing 'cdrom_id --lock-media /dev/sr0' [17485]
May 2 12:08:06 udevd[9591]: last message repeated 50 times
May 2 12:08:06 marius-T1005 kernel: [18963.080268] INFO: task usb_modeswitch:17507 blocked for more than 120 seconds.
May 2 12:08:06 marius-T1005 kernel: [18963.080281] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
...
May 2 12:08:06 marius-T1005 kernel: [18963.080292] usb_modeswitch D 00070509 0 17507 17470 0x00000000
May 2 12:08:06 marius-T1005 kernel: [18963.080310] c323dc80 00200086 c1069cdd 00070509 00000000 ffffffff c18f2380 c18f2380
May 2 12:08:06 marius-T1005 kernel: [18963.080340] c18f2380 c18f2380 7a6ecefc 00001110 c18f2380 f7007380 f2f23f20 f3ec3f20
May 2 12:08:06 marius-T1005 kernel: [18963.080366] f71073c4 006dd89d f71073ec dd51cbc0 00001110 00000000 00000001 c323dc78
May 2 12:08:06 marius-T1005 kernel: [18963.080393] Call Trace:
May 2 12:08:06 marius-T1005 kernel: [18963.080417] [<c1069cdd>] ? update_curr+0x24d/0x2a0
May 2 12:08:06 marius-T1005 kernel: [18963.080435] [<c106a530>] ? check_preempt_wakeup+0x140/0x220
May 2 12:08:06 marius-T1005 kernel: [18963.080451] [<c157d303>] schedule+0x23/0x60
May 2 12:08:06 marius-T1005 kernel: [18963.080465] [<c157b85d>] schedule_timeout+0x19d/0x260
May 2 12:08:06 marius-T1005 kernel: [18963.080480] [<c105d7ca>] ? check_preempt_curr+0x6a/0x80
May 2 12:08:06 marius-T1005 kernel: [18963.080493] [<c1062b30>] ? ttwu_do_wakeup+0x30/0x110
May 2 12:08:06 marius-T1005 kernel: [18963.080506] [<c1065e6e>] ? try_to_wake_up+0x1ce/0x230
May 2 12:08:06 marius-T1005 kernel: [18963.080520] [<c157d188>] wait_for_common+0xa8/0x120
May 2 12:08:06 marius-T1005 kernel: [18963.080533] [<c1065ed0>] ? try_to_wake_up+0x230/0x230
May 2 12:08:06 marius-T1005 kernel: [18963.080547] [<c157d2d7>] wait_for_completion+0x17/0x20
May 2 12:08:06 marius-T1005 kernel: [18963.080562] [<c104eefd>] wait_on_work+0x14d/0x160
May 2 12:08:06 marius-T1005 kernel: [18963.080575] [<c104d460>] ? do_work_for_cpu+0x20/0x20
May 2 12:08:06 marius-T1005 kernel: [18963.080...

Tested with kernel 3.4.0 rc5, so marking as Linux kernel upstream.

It might be a case of the modem not adhering to the standards. I remember a similar problem with Huawei sticks, exposed when the 2.6.32 kernel started to enforce protocols more strictly.

Anyway, this is well over my head and should probably go to the "linux-usb" mail list.

apport information

apport information

I have suggested previously to have a look at libusb (0 and 1). Are there any results yet?

See my comments above. I tested the compat 0/1 lib without any luck.

Hmm, after revisiting this whole thing, my conclusion is that if not even the "eject" tool works on a USB3 port, the issue must be in the kernel driver and/or hardware.

I will try to evoke this bug on my new machine.

I was not able to reproduce this on my machine, which has a Renesas chip for the USB 3.0 ports. Kernel is "3.2.0-27-generic".

No xHCI error, no problems with mode switching ...

Thanks for testing. I then assume it is something to do with my USB 3.0 hardware and probably not an error in usb_modeswitch. Found some tips here I am going to try:

http://forums.linuxmint.com/viewtopic.php?f=191&t=86640
http://forums.debian.net/viewtopic.php?f=7&t=61600

I have the same issue on an Asus UX21A (should be very similar to Cristophes UX31A). These laptops have Intel Panther Point USB controllers. So I doubt whether the problem is restricted to NEC uPD720200 controllers.

I didn't have time to test another kernel as requested higher in the thread, but I found a workaround in the usbmodeswitch forums :

http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=960

The idea is to "extract" the the configuration file from the collection in /usr/share/usb_modeswitch and then switch "manually" the modem.

For my modem, I took the file "12d1:1505" and made a small script to make the operation easier :

#!/bin/sh
/usr/sbin/usb_modeswitch -I -W -s 10 -c "12d1:1505" -v 12d1 -p 1505

Now all I have to do to switch the modem is : sudo ./switch

That's it !

Based on Christophe's post I modified /lib/udev/usb_modeswitch to wait for a number of seconds before running the modeswitch_dispatcher. Some experimenting determined the minimum number of seconds to be 11. My modem is now detected and switched automatically, even if I have to wait a few seconds longer than usual.

Obviously this is not a real solution but it might point someone more knowledgable in the right direction.

Patch attached.

It is actually working with command line, so I think the bug is in usb_modeswitch and not in the kernel.

But why is it working? Could it be that the modeswitching is started before the device is ready after it has been inserted? The "-I"switch is required for it to work. Without "-s 10" it still switches, but it gives error messages and indicate it failed (but running it again says there are no switchable devices).

The patch does not solve my problem. Do we talk about different issues here?

Could well be. Try increasing the delay to 30 though. If that doesn't help, we might be experiencing different problems with the same result.

The attachment "Patch for workaround" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

You are right. It worked with 30 seconds.

There might be a loose relation to bug #992639, where the storage driver attribute "delay_use" has some relevance:

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/992639

Anyway, all these timing problems seem to be rather system-specific. Apart from pointing to the tweakable parameters (like "WaitBefore" in the usb_modeswitch config files and "delay_use" for the usb-storage driver), I'm at a loss about how to tackle these issues *generally* ...

Seems like that. The option delay_use=3 to usb-storage also solves this.

What about adding retries when the switching fails?

So, it looks like usb-storage wants to have the device from t+1 until 1+11 (counting from the moment of insertion). usb_modeswitch wants to detach usb-storage at t+1 (exact numbers differ per chipset, apparently). This looks like a race condition, caused by various parties coding in arbitrary delays instead of using an event-based mechanism.

Pure speculation of course, but if this is really the root cause it would be nice if the usb-modeswitch people and the usb-storage people could agree on some sort of api to do this properly and without racing.

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 ...

I should note that I do not see any xHCI errors. There's simply nothing happening, most notably the modeswitch. :)

Has anybody been able to test the "ReleaseDelay" parameter ?

People,

I need *anybody* with the USB 3.0 problem test the "ReleaseDelay" parameter.

If that does not work, there is still plan B which is to alter the default "delay_use" option with the installation of usb_modeswitch. I can also let it check the setting with every run.

This would of course affect all devices using usb-storage, so I'd prefer an 'internal' solution.

12.10 is moving closer and I'll be off travelling in October, so I need a report *soon*.

Here is a little HowTo for conducting the test I requested:

There is a list (OR a package) of small config files in
/usb/share/usb_modeswitch.

Pick the one that matches your stick's ID in *install mode* (e.g. if the mode switch fails or if switching is disabled globally in
/etc/usb_modeswitch.conf).

Copy that file to "/etc/usb_modeswitch.d". It will now be preferred over the one in the default location.

Edit it and add a line:

ReleaseDelay=3000

This will make usb_modeswitch keep the device handle for 3 seconds after sending the switching command.
No guarantee, but it's worth a try.

If there is any effect, smaller values could be tested.

Ok, just tried the /etc/usbmodeswitch.d/ test :

Not working for me.. :(

All right, I extracted the file 12d1:1446 from configPack.tar.gz, put it in
/etc/usb_modeswitch.d and added the line ReleaseDelay=3000. There was no
difference in the result. :(

Negative result for me as well:
....
Blocking the interface for 3000 ms before releasing ...
....
 No new devices in target mode or class found

Mode switch has failed. Bye.

fail:
--------------------------------
(end of usb_modeswitch output)

USB dir exists: /sys/bus/usb/devices/6-2
Warning: USB attribute "serial" not readable.

All done, exiting

O.K., so the usb_modeswitch package should install a file in "/etc/modprobe.d" named "usb-storage.conf" with this content (or so):

--x--
# Increase the default delay to avoid conflict with usb_modeswitch

options usb-storage delay_use=3
--x--

Is there a way to check if there are other packages which set options for this module?

Also, the next program release will contain a check/set of the module attribute, so the mode switch would fail only once, even if the delay wasn'n pre-set.

Mathieu: I see you have done som development of this package before. Could you please help us resolving this and bug #992639? See question in comment #115.

Actually delay_use=2 is more than enough to fix things for me.

Since this is evidently hardware-dependent, the minimum value should better be confirmed by all reporters.

In any case, 2 or 3 seconds is still an improvement against the earlier kernel default which was 5 seconds, IIRC.

Pushing a file to change these settings with usb-modeswitch is not the right way to fix this. Instead, it's something that should be looked at directly by the kernel developers and change the timeout if it needs changing.

Bug 992639 is basically the exact same thing though, so I'll just mark this one as a duplicate of it, and bring it to kernel devs' attention.

I think it is the other way around as this one is older and have the solution.

#992639 even refers to the solution here.

"options usb-storage delay_use=3" works for me on Ubuntu 12.10 but not on Ubuntu 13.4.

delay_use=4 works for me on U13.04 (but on U12.10, delay_use=3 worked)

how did you set the delay?
in "/etc/modprobe.d" I have no file named "usb-storage.conf".

Some time ago, I created this bug-report for 13.04: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173566

LJ, you can just create a new file and add the option line.

thanks a lot; it works fine!

I confirm "delay_use=4" worked for me on 13.04 on a UX31A (same hardware as above) running kernel 3.8.0-26-generic

Marius B. Kotsbak, as per http://www.gigabyte.com/products/product-page.aspx?pid=3706#bios an update is available for your BIOS (F09). If you update to this, does it change anything?

If not, could you please both specify what happened, and provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

Thank you for your understanding.

Problem still exists in 14.04 LTS. Adding delay_use helps.

Fukanchik, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs