Hi
I'm running into an issue where the enumeration of a USB2.0 device failed due to lost interrupts.
This issue appears to occur randomly and we can only reproduce it on xHCI controllers that provide both USB3.0 and USB2.0 root hubs. Additionally, it is necessary to ensure that the first-level device under this controller is a SB2.0 device.
The above scenario can be referred to in the following figure.
----------------------------------------------------------------------------
| +---------------------------------+ |
| | xHCI Controller | |
| +---------------------------------+ |
| / \ |
| / \ |
| / \ |
| +-------------------------+ +---------------------------+ |
| | USB 3.0 Root Hub | | USB 2.0 Root Hub | |
| +------------------------+ +----------------------------+ |
--------------|-------------------------------------|-------------------------
| |
| [NO device] | [Device A]
| |
The USB topology displayed in the OS looks like this:
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/ , 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/ , 5000M
ID 1d6b:0003 Linux Foundation 3.0 root hub
This issue only occurs when the system reboot or when we insmod the xhci driver or ingister the xhci controller.
When the issue occurs, we can observe that the CPU receives fewer interrupts than what would normally be generated during the enumeration process, and there are error logs indicating command timeouts.
[ 2040.039438]xhci_hcd 0000:8a:00.7: Command timeout, USBSTS: 0x00000018 EINT PCD
[ 2040.039444] xhci_hcd 0000:8a:00.7: Command timeout
[ 2040.039446] xhci_hcd 0000:8a:00.7: Abort command ring
[ 2042.055435] xhci_hcd 0000:8a:00.7: No stop event for abort, ring start fail?
[ 2042.055469] xhci_hcd 0000:8a:00.7: Timeout while waiting for setup device command
[ 2042.064048] usb 15-1: hub failed to enable device, error -62
[ 2054.343446] xhci_hcd 0000:8a:00.7: Unsuccessful disable slot 1 command, status 25
[ 2066.631449] xhci_hcd 0000:8a:00.7: Error while assigning device slot ID: Command Aborted
[ 2066.640633] xhci_hcd 0000:8a:00.7: Max number of devices this xHCI host supports is 64.
[ 2066.649713] usb usb15-port1: couldn't allocate usb_device
After verification, we can confirm that the reason for the interrupt loss is that during the enumeration of U2 device,
U3 port is in a suspend procedure and performs an operation to disable interrupts in this function:
drivers/usb/host/xhci-hub.c
xhci_bus_resume()
/* delay the irqs */
temp = readl(&xhci->op_regs->command);
temp &= ~CMD_EIE;
writel(temp, &xhci->op_regs->command);
we can temporarily avoid this issue by modifying parameters.
echo -1 > /sys/module/usbcore/parameters/autosuspend
I am wondering whether there is a chance of interrupt loss occurring, regardless of whether or not it belongs to the scenario mentioned above? As long as an interrupt from a controller is triggered at exactly the same time as the process of disabling the controller's interrupts?
I read the xHCI protocol version 1.2 and haven't found detailed descriptions for such special cases. So I was wondering what is the main reason for disabling interrupts in xHCI driver during the resume process?
Additionally, given that there is a conflict between interrupt handling and the resume process, does our protocol require controllers to ensure they should trigger interrupt signals after interrupt has been re-enabled, even if the driver hasn't cleared the EHB? (This should also apply in cases where edge-triggered interrupts are used.)
Or should the xHCI driver software check and handle the controller's interrupt status when an error occurs, by polling for interrupt flags?
Thanks in advance for any insights!
Devyn Liu
liudingyuan@xxxxxxxxxx
