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
