The xHCI driver's code has this comment:
~~~
/* Section 4.6.1.2 of xHCI 1.0 spec says software should also time the
* completion of the Command Abort operation. If CRR is not negated in 5
* seconds then driver handles it as if host died (-ENODEV).
* In the future we should distinguish between -ENODEV and -ETIMEDOUT
* and try to recover a -ETIMEDOUT with a host controller reset.
*/
ret = xhci_handshake(&xhci->op_regs->cmd_ring,
CMD_RING_RUNNING, 0, 5 * 1000 * 1000);
~~~
This 5 second is in xHCI spec, it's not configurable on kernel side. And should
be there for other OS too.
At my knowledge, most of the timeouts in OpenOCD are randomly chosen by the
developer. Timeouts in flash drivers are often taken from memory datasheet, but
the rest is just "some reasonable value".
>From the comment above, the USB stack can try to recover, so eventually
>succeed and returns a valid reply after 5 seconds. Imagine this during a
>"halt" request that timeouts after 2 seconds. The halt succeed but well after
>2 seconds and you get an error!
I'm afraid that we just start stretching one timeout now and later we have to
extend one after the other...
Anyway, this 5 seconds is in xHCI spec, so I agree to this fix.
But please properly explain the reason in a comment above the new 6 second
value.
The proposed fix is for CMSIS-DAP, but all other USB drivers need the same.
Having the proper explanation would help other driver's development. And maybe
in future the timeout should be moved in some common libusb wrapper, outside
the driver.
Also libjaylink should revisit its 1 second USB_TIMEOUT macro.
---
** [tickets:#343] Increase CMSIS_DAP usb timeout value**
**Status:** new
**Milestone:** 0.10.0
**Created:** Fri Mar 18, 2022 10:08 AM UTC by Gabor
**Last Updated:** Mon Mar 21, 2022 02:25 AM UTC
**Owner:** nobody
The linux USB stack locks up for 5 seconds if there's an unreponsive USB
device, while linux is trying to reconnect.
If I halt my device under test, it causes the above linux usb stack bug and my
openOCD connection with my DAPLink breaks.
The best solution I've found is increasing the USB_TIMEOUT to 6000ms in
cmsis_dap.c. What do you think about submitting this fix? If there's an easy
way for me to create the CL, I'm happy to do so.
---
Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/openocd/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
