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

[Dane Linssen]

Hi Michal,

> Looking at the log below I'm not sure if it will help.

Agreed. All four soft retries failed within about 14 ms, so I'll skip
the retry patch unless you think it's still worth a try.

> 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?

The pcaps don't reach back that far. The watchdog takes them when it
notices the stall, 8 to 33 s after the first error. In each of them
0x81 completes only with -71, and 0x02 and 0x83 complete with 0.

What I do have about the onset:

- xhci dynamic debug logs every "Transfer error", on any endpoint.
  Each burst starts on ep 2 (0x81), and no other endpoint logs an
  error near any of the stalls.
- Nothing else is in the kernel log in the 20 s before any onset:
  no carrier change, no USB event.
- Traffic is sampled once a minute, so it can't show a 15 ms gap in
  TX. Averages in the minutes before each onset:

    10-09, 4 stalls   NFS copies, 25-40 MB/s each way
    10-26 19:31       250-480 packets/s each way, under 0.5 MB/s
    10-26 20:19       1.8k-2.0k packets/s each way, about 2.5 MB/s

  So heavy traffic isn't needed, although the 09-27 and 10-09
  stalls came under load.

The onset is the same in all eight stalls logged with dynamic debug
(10-04 to 10-26): four soft resets about 3.5 ms apart, then the hard
reset 13.6 to 15.5 ms after the first error. After the hard reset the
-71 completions keep that pace, about one per 3.6 ms (~275/s). So
each soft retry takes as long to fail as the transfers after the
endpoint is out of sync.

Since my last mail there were six more stalls, all with virt_state
0x40, each fixed by the watchdog's rebind: four on 10-09 within
20 minutes (kernel 7.2.7) and two on 10-26 (7.2.11).

> 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.

I can test a patch like that here. Since today (10-28) this host no longer
runs cluster workloads and the adapter is on another USB port, so I
don't know how often it will stall now.

> 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.

Without a clear_halt it never resynchronized here. The longest stall
left alone (09-27) still read virt_state 0x40 after 15 minutes, and
RX only came back with the rebind after 23 minutes.

For the Realtek side: RTL8156B, 0bda:8156, bcdDevice 31.04, firmware
rtl8156b-2 v3 10/20/23, on an Intel xHCI (8086:9d2f) at 5 Gbps.

Thanks,
Dane

On Tue, Oct 13, 2026 at 11:25 PM Michal Pecio <michal.pecio@xxxxxxxxx> wrote:
>
> [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