Re: Strange behavior with ZTE MF821D (and possible other MDM9200 devices)
Hi all, After spending more time experimenting and trying to solve this problem, we have sort-of come to a conclusion. In case anyone else finds it interesting, I thought I should share it here. Our findings can be summarized as follows: - The problem is triggered by the switch from 3G to 2G. I can reliably trigger it by sending AT+ZSNT=1,0,0 to the modem or setting system selection to 0x0004 (both locking MF821D to 2G). - The root cause is the modem, but I can trigger the error on different USB hosts. I have been able to replicate it on the earlier mention router, my two laptops (with Intel-chipsets), a Raspberry Pi and some commercial mobile broadband routers. However, some hosts seem more resilliant than others. One for example the TP-Link I can trigger it all the time, while on my laptop it is more seldom. - One theory that we have not been able to verify is that the problem is somehow related to ISP. I got some friends in another country to try the AT-command with MF821D and the TP-Link WDR4300, and they did not see it. - I tried the same with another modem I have, the Huawei E392. I had no problems locking to 2G or moving between 3G/2G. - Our current work-around is to disable 2G. After doing this we have not seen this problem. -Kristian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Strange behavior with ZTE MF821D (and possible other MDM9200 devices)
Hi Markus, On Tue, Dec 3, 2013 at 9:08 PM, Markus Gothe wrote: > This is a know issue with some MF821D firmwares. > I believe it is due to some sort of hibernation mode. Thank you very much for letting me know. Do you know of any strategies people have used to work around this issue, or if it is possible to disable this mode? -Kristian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Strange behavior with ZTE MF821D (and possible other MDM9200 devices)
This is a know issue with some MF821D firmwares. I believe it is due to some sort of hibernation mode. //Markus - The panama-hat hacker On 03 Dec 2013, at 15:48 , Kristian Evensen wrote: > Hei Bjørn, > > On Tue, Dec 3, 2013 at 3:37 PM, Bjørn Mork wrote: >> The most likely cause of this is a modem firmware crash. I don't think >> there is much you can do about that, except trying to avoid the >> situations which causes the crash or getting another modem. > > Ok, that is what I suspected, thank you very much for letting me know. > Then I guess we have to live with some work-arounds. One interesting > observation is that the modem seems to reboot by itself and works just > fine once the USB queue (probably not the correct name) has been > flushed, so we will try to speed up the flush when packets with status > -71 arrives. I guess this will be a special case solution and not > something that should be submitted as a patch to the kernel. > > Thanks again for the help, > Kristian > ___ > libqmi-devel mailing list > libqmi-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libqmi-devel signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Strange behavior with ZTE MF821D (and possible other MDM9200 devices)
Hei Bjørn, On Tue, Dec 3, 2013 at 3:37 PM, Bjørn Mork wrote: > The most likely cause of this is a modem firmware crash. I don't think > there is much you can do about that, except trying to avoid the > situations which causes the crash or getting another modem. Ok, that is what I suspected, thank you very much for letting me know. Then I guess we have to live with some work-arounds. One interesting observation is that the modem seems to reboot by itself and works just fine once the USB queue (probably not the correct name) has been flushed, so we will try to speed up the flush when packets with status -71 arrives. I guess this will be a special case solution and not something that should be submitted as a patch to the kernel. Thanks again for the help, Kristian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Strange behavior with ZTE MF821D (and possible other MDM9200 devices)
Kristian Evensen writes: > We are currently facing a USB problem that we have not been able to > solve. A USB ACK is not sent and the following messages appear in the > kernel logs: > Thu Nov 21 09:44:53 2013 kern.err kernel: [ 490.60] qmi_wwan > 1-1.1.2:1.4: nonzero urb status received: -71 > Thu Nov 21 09:44:53 2013 kern.err kernel: [ 490.60] qmi_wwan > 1-1.1.2:1.4: wdm_int_callback - 0 bytes The most likely cause of this is a modem firmware crash. I don't think there is much you can do about that, except trying to avoid the situations which causes the crash or getting another modem. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Strange behavior with ZTE MF821D (and possible other MDM9200 devices)
Hello, I am currently working on a project where we are building devices that will be placed on moving objects (buses, trains, etc.). The devices are routers (TP-Link WDR4300) based on the Atheros AR9344 SoC and running OpenWrt with kernel 3.10.18. The purpose of these devices is to measure the mobile broadband performance, of both HSDPA and LTE, and the modem we are currently working with is the ZTE MF821D (QMI). The reason is that this is the modem used the two biggest operators and it exports the information we need. We are currently facing a USB problem that we have not been able to solve. A USB ACK is not sent and the following messages appear in the kernel logs: Thu Nov 21 09:44:53 2013 kern.err kernel: [ 490.60] qmi_wwan 1-1.1.2:1.4: nonzero urb status received: -71 Thu Nov 21 09:44:53 2013 kern.err kernel: [ 490.60] qmi_wwan 1-1.1.2:1.4: wdm_int_callback - 0 bytes This can go on for several minutes, during which USB is non-responding. After this time period has passed, USB starts responding again, the modems disconnect/connect and work again. Initially we suspected a bug in the USB hub on the SoC, but after some great help from Alan Stern that seems not to be the case. A summary of our initial observations can be found here: http://thread.gmane.org/gmane.linux.usb.general/99142 Instead, it seems like the issue is caused by the modem. The common behavior is that the modem is moved into areas where there is no data coverage (LED turns red), but it does not loose packet service. When it gets service again (LED turns blue/green), the error occurs. The following then appears in the log file (along with the XactErr-messages described in my other email): [ 2185.29] qmi_wwan 1-1.1.3:1.4: nonzero urb status received: -71 [ 2185.29] qmi_wwan 1-1.1.3:1.4: wdm_int_callback - 0 bytes [ 2185.47] qmi_wwan 1-1.1.2:1.4: nonzero urb status received: -71 [ 2185.47] qmi_wwan 1-1.1.2:1.4: wdm_int_callback - 0 bytes [ 2185.50] qmi_wwan 1-1.1.3:1.4: nonzero urb status received: -71 [ 2185.50] qmi_wwan 1-1.1.3:1.4: wdm_int_callback - 0 bytes [ 2185.59] qmi_wwan 1-1.1.2:1.4: Error in flush path: -71 [ 2185.60] qmi_wwan 1-1.1.3:1.4: Error in flush path: -71 In order to get the "Error in flush path", we first had to remove the option module. Otherwise, we would only see (in addition to wdm_int_callback + nonzero urb): [62979.28] option1 ttyUSB7: option_instat_callback: error -71 We are currently a bit stomped and unsure how to progress. Our qmi-dialer is exited and lsof shows that no applications have the wdm-device open. We have tested with modems with different chipsets (older Huawei 3G modems), and they do not display this issue, so it seems to be a modem or chipset issue. We ran some tests with a ZTE MF823D WebUI (also based on MDM9200) modem and saw some strange behavior with it as well. My question is, has anyone seen this behavior or have any hints as to how we can progress? I implemented a quick hack in which I reduced the number of retransmissions of a USB packet to a driver, in order to shorten the time until USB becomes responsive again. It works, but it is not very nice and seems to cause problems elsewhere. Thanks in advance for any help, Kristian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
