Re: My transfer ring grew to 740 segments

["Michał Pecio" <michal.pecio@gmail.com>]

On Fri, 14 Mar 2025 19:15:36 +0000, David Laight wrote:
> Several years ago I found a bug in one of the asmedia chips that it
> only processed one entry from the command ring each time the doorbell
> was rung (the normal transfers were fine).
> It would get 'out of step' so every time you sent a new command an
> old one got executed instead - very confusing.


Interesting, but it doesn't seem to reproduce here.
I tried Promontory, ASM3142, ASM1142, ASM1042.

I removed the check for running endpoint from xhci-hub.c stop_device()
so it queues a Stop EP for each endpoint (as was done before 2017) and
then rings the command doorbell once (as it always did).

This is called before autosuspend so I would expect autosuspend to be
broken by such a bug, particularly before 2017.

The worst I got was a Stopped event from ASM1042 for a command failing
with Context State Error, IIRC it's illegal. But both cmds completed:

[  +2,271097] xhci_hcd 0000:02:00.0: 1/6 (000/3) queue_stop_endpoint suspend 1
[  +0,000006] xhci_hcd 0000:02:00.0: 1/0 (040/1) queue_stop_endpoint suspend 1
[  +0,000003] xhci_hcd 0000:02:00.0: 0/-1 (fff/f) xhci_ring_cmd_db cmd_ring_state 1
[  +0,000047] xhci_hcd 0000:02:00.0: 1/6 (000/3) handle_tx_event comp_code 26 trb_dma 0x000000000341d010
[  +0,000036] xhci_hcd 0000:02:00.0: 1/6 (000/3) handle_cmd_completion cmd_type 15 comp_code 19
[  +0,000142] xhci_hcd 0000:02:00.0: 1/0 (040/1) handle_tx_event comp_code 26 trb_dma 0x0000000003415640
[  +0,000038] xhci_hcd 0000:02:00.0: 1/0 (040/3) handle_cmd_completion cmd_type 15 comp_code 1

Was it supposed to happen every time, or only randomly?

> I don't remember seeing the bug 'worked around' while I was actively
> looking at the changes - so it may still be present.
> So setting up the ethernet interface I was using only worked most of
> the time. Reproducible by adding two commands but only ringing the
> bell once. I fixed it by ringing the doorbell again in the completion
> interrupt path.

I don't see any evidence of such workaround today.

Regards,
Michal