From: Julian Oes <julian@oes.ch>
To: gregkh@linuxfoundation.org
Cc: johan@kernel.org, oneukum@suse.com, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, Julian Oes <julian@oes.ch>
Subject: Re: [PATCH v2] USB: serial: generic: recover from a stalled bulk-in endpoint
Date: Wed, 2 Sep 2026 10:44:44 +1200 [thread overview]
Message-ID: <20260901224447.50777-1-julian@oes.ch> (raw)
In-Reply-To: <2026090142-walrus-zipfile-70d1@gregkh>
On Tue, Sep 01, 2026 at 06:33:15AM +0200, Greg Kroah-Hartman wrote:
> This sounds like a broken hub, why not just replace that? It shouldn't
> be causing transactions on a different port to stop.
I agree that ideally my hub would not do that. However, my assumption is
that it's not my specific hub that is broken, but that this hub (or
other hubs on the same chip) have that sort of issue, and I was hoping
to be able to fix it for me and others in software, rather than brush it
off as a hardware issue.
From what I understand an endpoint halt is spec-defined as
host-recoverable. In the current state (without the patch) the read
never returns data again and the user doesn't know that it needs
restarting.
My patch is meant to do the same pattern that cdc-acm already does:
EVENT_RX_STALL → kill → usb_clear_halt → resubmit.
> > +#define USB_SERIAL_STALL_COOLDOWN msecs_to_jiffies(10)
>
> control or bulk? This comment does not make much sense.
Sorry, it's not clear. Both: the halted endpoint is the bulk-in one,
but the CLEAR_FEATURE that clears it goes to the control pipe, so one
recovery attempt is a control transfer plus a bulk resubmit.
Without the delay I saw six stalls in six milliseconds. The clear-halt
succeeds every time, but the hub re-stalls the endpoint as soon as a
read is queued, until the transient is over.
The delay is there to stop that becoming a tight loop.
I can reword it for v3, depending on whether you agree that a stall
needs clearing at all.
For a bit of context: in the past 14 years, I have been working with
various FTDI and similar USB devices, and it's possible that I have seen
this issue every so often. Usually, I would just re-open screen, try a
different USB port or hub, restart the hub, etc. It's only this time
that I stumbled on a reproducible case, and had the capacity to dig
deeper using an LLM.
I have been using the v1 patch that I submitted in May ever since and
have not noticed such issues anymore.
Thanks,
Julian
next prev parent reply other threads:[~2026-09-01 22:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 3:49 [PATCH v2] USB: serial: generic: recover from a stalled bulk-in endpoint Julian Oes
2026-09-01 4:33 ` Greg Kroah-Hartman
2026-09-01 22:44 ` Julian Oes [this message]
2026-09-01 8:28 ` Oliver Neukum
2026-09-01 23:13 ` Julian Oes
2026-09-02 4:42 ` Michal Pecio
2026-09-02 8:40 ` Oliver Neukum
2026-09-02 14:33 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260901224447.50777-1-julian@oes.ch \
--to=julian@oes.ch \
--cc=gregkh@linuxfoundation.org \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox