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.600000] qmi_wwan 1-1.1.2:1.4: nonzero urb status received: -71 Thu Nov 21 09:44:53 2013 kern.err kernel: [ 490.600000] 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.290000] qmi_wwan 1-1.1.3:1.4: nonzero urb status received: -71 [ 2185.290000] qmi_wwan 1-1.1.3:1.4: wdm_int_callback - 0 bytes [ 2185.470000] qmi_wwan 1-1.1.2:1.4: nonzero urb status received: -71 [ 2185.470000] qmi_wwan 1-1.1.2:1.4: wdm_int_callback - 0 bytes [ 2185.500000] qmi_wwan 1-1.1.3:1.4: nonzero urb status received: -71 [ 2185.500000] qmi_wwan 1-1.1.3:1.4: wdm_int_callback - 0 bytes [ 2185.590000] qmi_wwan 1-1.1.2:1.4: Error in flush path: -71 [ 2185.600000] 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.280000] 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
