Re: git: 28d85db46b48 - main - xhci: Do not drop and add bits in xhci

On Sat, 11 Jul 2026 at 20:21, Kyle Evans <kevans@freebsd.org> wrote:
>
> On 5/22/26 02:41, ShengYi Hung wrote:
> > The branch main has been updated by aokblast:
> >
> > URL: https://cgit.FreeBSD.org/src/commit/?id=28d85db46b484589e2ee74cf4b270db066821de1

> Hi,
>
> This patch reliably fixes a bug I've been trying to track down in a u2f(4) patch
> that I've been testing, and I'm wondering if you can help connect the dots.  I
> have a Solo2 u2f(4) key that I find will inconsistently desync (for other reasons)
> and hang, and the solution for *that* is to release this NOT_YET block[0] in
> u2f_dtor().
>
> The problem I was hunting down is that doing so subsequently broke my Yubikey in a
> way that this patch alone seems to fix.  It would hang on every other ssh attempt, as
> long as we issued usbd_transfer_stop on our interrupt endpoints upon last-close.  It
> was known to work with uhid(4) reliably which issues a stop as well, and that's the
> thing I can't really explain.  Is there something that uhid(4) / usb_dev.c is doing
> that might have accidentally worked around this?
>
> This was the only commit that looked relevant in the fast-forward I did for my latest
> round of testing from 9c18d55a768a3 to 707ee7ff952c5, and reverting just this patch
> reliably re-introduces the problem I was having with the Yubikey.
>

My guess is the yubikey device firmware pays attention to this bit and
the state is
only reset when the state cycles through STOP. If you're curious, try
comparing usbdump
captures before/after the fix and look for explicit differences in
things and then
guess what the firmware is doing.


-adrian