On Tue, Jul 21, 2020 at 07:59:17AM +0200, Michal Hocko wrote: > > Sorry, my mistake. The module name needs to be "xhci_hcd" with an '_' > > character, not a '-' character -- the same as what shows up in the lsmod > > output. > > > [14766.973734] xhci_hcd 0000:00:14.0: Get port status 2-1 read: 0xe000088, return 0x88 > [14766.973738] xhci_hcd 0000:00:14.0: Get port status 2-2 read: 0xe000088, return 0x88 > [14766.973742] xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0xe0002a0, return 0x2a0 > [14766.973746] xhci_hcd 0000:00:14.0: Get port status 2-4 read: 0xe0002a0, return 0x2a0 > [14766.973750] xhci_hcd 0000:00:14.0: Get port status 2-5 read: 0xe0002a0, return 0x2a0 > [14766.973754] xhci_hcd 0000:00:14.0: Get port status 2-6 read: 0xe0002a0, return 0x2a0 > [14766.973759] xhci_hcd 0000:00:14.0: Get port status 2-1 read: 0xe000088, return 0x88 > [14766.973763] xhci_hcd 0000:00:14.0: Get port status 2-2 read: 0xe000088, return 0x88 According to the xHCI specification, those 02a0 values are normal and the 0088 values indicate the port is disabled and has an over-current condition. I don't know about the e000 bits in the upper part of the word; according to my copy of the spec those bits should be 0. If your machine has only two physical SuperSpeed (USB-3) ports then perhaps the other four ports are internally wired in a way that creates a permanent over-current indication. > [14766.973771] xhci_hcd 0000:00:14.0: set port remote wake mask, actual port 0 status = 0xe000088 > [14766.973780] xhci_hcd 0000:00:14.0: set port remote wake mask, actual port 1 status = 0xe000088 > [14766.973789] xhci_hcd 0000:00:14.0: set port remote wake mask, actual port 2 status = 0xe0002a0 > [14766.973798] xhci_hcd 0000:00:14.0: set port remote wake mask, actual port 3 status = 0xe0002a0 > [14766.973807] xhci_hcd 0000:00:14.0: set port remote wake mask, actual port 4 status = 0xe0002a0 > [14766.973816] xhci_hcd 0000:00:14.0: set port remote wake mask, actual port 5 status = 0xe0002a0 > [14766.973830] xhci_hcd 0000:00:14.0: Bus suspend bailout, port over-current detected > > Repeating again and again. The last message suggests a HW problem? But > why does the kernel try the same thing over and over? Because over-current is supposed to be a transient condition that goes away quickly. It means there's a short circuit or something similar. > > You could also try collect a usbmon trace from the .../2u file. It does > > seem that bus 2 is where the problem occurs. > > a random sample ... > ffff888040808cc0 2551256922 S Ci:2:001:0 s a3 00 0000 0001 0004 4 < > ffff888040808cc0 2551256925 C Ci:2:001:0 0 4 = 88000000 > ffff888040808cc0 2551256927 S Ci:2:001:0 s a3 00 0000 0002 0004 4 < > ffff888040808cc0 2551256933 S Ci:2:001:0 s a3 00 0000 0003 0004 4 < > ffff888040808cc0 2551256936 C Ci:2:001:0 0 4 = a0020000 > ffff888040808cc0 2551256942 C Ci:2:001:0 0 4 = a0020000 ... The usbmon output has a lot of gaps, but here we can see some of the port status data contains 0x0088 (four bytes little-endian) and some contains 0x02a0 -- the same as what the debugging log says. So yes, this looks like a hardware design error. Turning off autosuspend by writing to the sysfs power/control file is probably the best way to handle the problem. Alan Stern
