On 02.10.2017 22:44, Kristian Evensen wrote:
Hello,
I am currently working on a custom Armada 385-based board running
kernel 4.9.52. I have a USB 2.0 LTE modem connected to USB 3.0, and
the modem sometimes crashes due to various internal (on the modem)
reasons. The board supports restarting the USB-ports using GPIOs, and
at random points when I restart the USB-port I get the following error
in dmesg:
[12446.639458] qmi_wwan 4-1:1.4: nonzero urb status received: -71
[12446.639462] qmi_wwan 4-1:1.4: wdm_int_callback - 0 bytes
[12446.639466] qmi_wwan 4-1:1.4: wdm_int_callback - usb_submit_urb
failed with result -19
[12446.658760] option1 ttyUSB0: GSM modem (1-port) converter now
disconnected from ttyUSB0
[12446.666837] option 4-1:1.0: device disconnected
[12446.671576] option1 ttyUSB1: GSM modem (1-port) converter now
disconnected from ttyUSB1
[12446.679686] option 4-1:1.1: device disconnected
[12451.763245] xhci-hcd f10f8000.usb3: xHCI host not responding to
stop endpoint command.
[12451.771187] xhci-hcd f10f8000.usb3: Assuming host is dying, halting host.
[12451.778027] xhci-hcd f10f8000.usb3: HC died; cleaning up
[12451.783589] option1 ttyUSB2: GSM modem (1-port) converter now
disconnected from ttyUSB2
[12451.791654] option 4-1:1.2: device disconnected
[12451.796416] option1 ttyUSB3: GSM modem (1-port) converter now
disconnected from ttyUSB3
[12451.804530] option 4-1:1.3: device disconnected
[12451.809206] qmi_wwan 4-1:1.4 wwan0: unregister 'qmi_wwan'
usb-f10f8000.usb3-1, WWAN/QMI device
After this, the port is dead until I reboot the device and it is
sufficient to do a soft reboot in order to bring the port back. Most
of the time, restarting the port works fine and the time it takes for
the error to occur seems random.
In order to rule out (or at least reduce the probability of) that
there is something wrong with the board I am testing, I found two
other Armada-boards with upstream-support and compiled kernel 4.14-rc3
for them. The modem can be rebooted using AT-commands, so I created a
small script which contained a loop where I rebooted the modem as soon
as possible. Doing this, I was able to replicate the error I saw on my
custom board-
Does anyone have any tips on where to start looking, how to solve this
issue or how to work around it? For me, if there is a way to restart
the host controller, then that would be sufficient as I only have one
USB device connected. When searching online, I find lots of references
to similar issues, but they all (or at least the ones where a solution
has been found) seem to related to suspend/resume.
For temporary workarounds:
if xhci is a module then unload and reload in using modprobe
Or then unbind/rebind the driver and device.
on a Intel PCI based xhci it would be something like:
echo 0000:00:14.0 > /sys/bus/pci/drivers/xhci_hcd/unbind
echo 0000:00:14.0 > /sys/bus/pci/drivers/xhci_hcd/bind
On your Armada xhci might be found under the platform bus instead of PCI,
and ID won't be 0000:00:14.0, but you get the idea.
If you want to try messing around with the driver itself you could try to
just disable the xhci stop command timer.
The timer is there for a reason, but it's also possible that your command queue
is
just clogged because its trying to address the faulty device.
You could play around and remove the timer and see what happens:
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index df0a82b..b0e7083 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1518,7 +1518,6 @@ static int xhci_urb_dequeue(struct usb_hcd *hcd, struct
urb *urb, int status)
ep->ep_state |= EP_STOP_CMD_PENDING;
ep->stop_cmd_timer.expires = jiffies +
XHCI_STOP_EP_CMD_TIMEOUT * HZ;
- add_timer(&ep->stop_cmd_timer);
xhci_queue_stop_endpoint(xhci, command, urb->dev->slot_id,
ep_index, 0);
xhci_ring_cmd_db(xhci);
-Mathias
--
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
