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

[Dane Linssen]

Thanks, everyone, for the quick replies.

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.
Bisecting isn't practically possible, as the stalls are days apart.

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.

> As a bandaid, you could try increasing MAX_SOFT_RETRY or this:
> https://lore.kernel.org/linux-usb/20260905101837.4b7849c5.michal.pecio@xxxxxxxxx/

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 mentioned using dynamic debug. Do you see "Transfer error"
> messages randomly during operation, or is it only one burst right
> before the failure?

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.

> This should be visible with usbmon.

usbmon's debugfs files are blocked by lockdown here, but /dev/usbmonN
works, so if I have another stall I can send a 2 s usbmon capture of
the bus as well.

Regards,
Dane