Re: r8152: RX stops until rebind after -EPROTO on the bulk-in endpoint

[Michal Pecio <michal.pecio@gmail.com>]

On Mon, 28 Sep 2026 14:48:05 +0200, Dane Linssen wrote:
> Andrew:
> As far as I can tell it isn't a regression. The adapter is new
> (2026-09-17) and has only run 7.2.5 and 7.2.6, which don't differ in
> r8152 or xhci. e765ab012f73 ("usb: xhci: Improve Soft Retries after
> short transfers", v7.1) should make it rarer, not more common.

IDK if it's a regression or not, but the symptoms seem consistent
with a know problem which exists since forever.

> Michal:
> > Out of curiosity, what's your xHCI chip?  
> 
> Intel Sunrise Point-LP, 8086:9d2f (i5-8250U), so not ASMedia. The
> other host with the same adapter, which hasn't stalled, has an Intel
> Comet Lake-LP, 8086:02ed.

OK, thanks.

> > As a bandaid, you could try increasing MAX_SOFT_RETRY or this:
> > https://lore.kernel.org/linux-usb/20260905101837.4b7849c5.michal.pecio@gmail.com/  
> 
> Thank you. Would you like me to try this to gather more data? If not,
> I already have a userspace watchdog that rebinds r8152 when the LAN is
> unreachable and the bulk-in endpoint shows virt_state 0x40.

You could try it. We may consider increasing retries in mainline if
this turns out to solve real world problems. Though so far, in the only
reported case of 3 retries not working, 10 retries over a span of 100ms
weren't helping either...

> I only enabled it after the two stalls I reported. In the 19 hours
> since, including 71 minutes above 5k rx packets/s (peak about 29k),
> there hasn't been a single "Transfer error" message, and no stall. So
> nothing random so far. The next stall will show whether it's a burst.

Any results yet?

Regards,
Michal