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

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

[Adding Realtek people who contributed to r8152 before]

On Fri, 9 Oct 2026 14:23:57 +0200, Dane Linssen wrote:
> > 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...  
> 
> Thanks, I'd like to try it. It needs some setup here first (signed
> modules), so it may take a while before I can report back.

Looking at the log below I'm not sure if it will help. 15 ms is quite
a long time and my gut feeling is that a temporary link disruption
would be unlikely to last so long and not affect TX, unless TX is idle
through all that time. Do you still have those usbmon logs, were other
endpoints active in the 15 ms preceding the first -71 status?

Absence of errors at other times suggests that this is not a case of
barely functional cable causing high rate of USB packet loss.

The other possibility is that a HW bug gets the endpoint in some bogus
state and only resetting the endpoint or whole device can fix it. Maybe
resetting the RX endpoint would suffice, and the driver schedules some
work on -EPROTO where usb_clear_halt() could be inserted.

Question remains, how to get the chip to abort the botched transfer
and start a new transfer into a new URB cleanly? Is it enough to keep
submitting URBs and eventually things will resynchronize? The driver
seems to believe so, but does this really work? It will need to.

> > Any results yet?  
> 
> Yes: three more stalls on the same host in 11 days (09-30, 10-04,
> 10-06), all with virt_state 0x40, each recovered by the watchdog's
> rebind in about 30 s. Dynamic debug was on for the last two. Both
> start with a single burst, and in the 11 days there wasn't one
> "Transfer error" on ep 2 outside the stalls. 10-04:
> 
>   22:36:09.251 Transfer error for slot 4 ep 2 on endpoint
>   22:36:09.252 Soft-reset ep 2, slot 4
>   22:36:09.255 Transfer error for slot 4 ep 2 on endpoint
>   22:36:09.255 Soft-reset ep 2, slot 4
>   22:36:09.258 Transfer error for slot 4 ep 2 on endpoint
>   22:36:09.259 Soft-reset ep 2, slot 4
>   22:36:09.262 Transfer error for slot 4 ep 2 on endpoint
>   22:36:09.262 Soft-reset ep 2, slot 4
>   22:36:09.265 Transfer error for slot 4 ep 2 on endpoint
>   22:36:09.266 Hard-reset ep 2, slot 4
> 
> From there it's Transfer error + Hard-reset pairs at about 275/s
> until the rebind 40 s later. 10-06 is the same: four soft retries
> about 3.5 ms apart, the hard reset at +15 ms, then the same loop.
> So here all the retries are spent within 15 ms.

After "hard reset" it's a 97% chance of endpoint sequence state being
out of sync. On USB3, resubmitting without usb_clear_halt() is futile.

Notice how baf33d7a7564 ("r8152: avoid to resubmit rx immediately")
only talks about disconnection and not recovering from these errors.
I suspect no one has seen such recovery, at least on USB3. Easily
recoverable errors don't reach drivers due to retries in HW and SW.

> usbmon, 2 s from each of the three stalls: every bulk-in (0x81)
> completion is -71 (571, 553 and 551 of them), none succeed, and
> bulk-out and the interrupt endpoint complete normally.
> 
> The other host with the same adapter logged no transfer errors at
> all in the same 11 days.
> 
> Dane