Repository navigation
[Question] How should mctp‑usb handle TX URB timeouts to recover when the device stops responding and recovers after some time? #11
Description
Hi Jeremy,
Quick question on the MCTP-over-USB driver: what’s the mechanism by which a submitted URB gets cancelled, leading to a stopped network queue being woken up?
In the upstream implementation (mainline mctp-usb.c: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/mctp/mctp-usb.c), it looks like the queue is woken in mctp_usb_out_complete() after a successful URB completion. This makes me wonder whether delayed/non-successful completions can keep the TX queue stopped long enough for the skb backlog to hit limits and surface as ENOBUFS to userspace.
Do the multi‑URB enhancements in this branch address that behavior?
https://github.com/CodeConstruct/linux/blob/test/mctp-usb/drivers/net/mctp/mctp-usb.c
If yes, what’s the current line of sight / plan for upstreaming those changes?
Thanks,
Suresh
Activity
jk-ozlabs commentedon Mar 3, 2026
Yes, an error completion will not re-start the TX queues; at that point, we don't have any indication when (or if) we are able to resume TX to the device.
The upstream driver is pretty simple, and is conservative with URB queuing. If you have conditions where the hardware is stopping and then recovering, I would like to see the patterns of completions that you're seeing over that span to determine what the recovery mode should be.
The mutli-urb implementation does handle this, yes. I don't have any specific timeline for upstreaming (I have a couple of improvements in mind still), but any results of your testing would be helpful for that process.
suresh-vijay-msft commentedon Mar 6, 2026
Thanks, Jeremy, for your reply. I’ll test multi‑URB in parallel while capturing URB status using a single URB to pinpoint the issue and then follow up so we can discuss enhancements to the recovery approach.
jk-ozlabs commentedon Mar 6, 2026
Sounds good.
If you're investigating hardware behaviour, you may want to keep things simple and stick to single-URBs, but you'll need a temporary workaround to re-submit on error, in order to capture the subsequent completion status. We'd also want to log if the resubmit fails.
Timeouts would require more infrastructure, but I am not sure if you need that at this point?