Date: Sun, 12 Jul 2026 12:19:10 -0500 From: Kyle Evans <kevans@FreeBSD.org> To: Adrian Chadd <adrian@freebsd.org> Cc: ShengYi Hung <aokblast@freebsd.org>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org, Vladimir Kondratyev <wulf@freebsd.org> Subject: Re: git: 28d85db46b48 - main - xhci: Do not drop and add bits in xhci Message-ID: <07894a56-cdfb-40dc-8746-60eaf596e4c4@FreeBSD.org> In-Reply-To: <CAJ-VmokYaCgRfhC2TM6ByuLqByx0ayH=GuSVhSG7W1JYe7LZGQ@mail.gmail.com> References: <6a1008a0.3f79c.1d455f29@gitrepo.freebsd.org> <49761290-2d6c-403f-acdd-48b5b536804c@FreeBSD.org> <CAJ-VmokYaCgRfhC2TM6ByuLqByx0ayH=GuSVhSG7W1JYe7LZGQ@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On 7/12/26 10:43, Adrian Chadd wrote: > 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. > Solid suggestion, thanks- I forgot that usbdump is even a thing, so I'll play with this a bit. Thanks, Kyle Evanshome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?07894a56-cdfb-40dc-8746-60eaf596e4c4>