[Bug 221073] xHCI host controller dies on resume from s2idle on AMD Strix Halo [1022:1587]

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221073

Mathias Nyman (mathias.nyman@linux.intel.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mathias.nyman@linux.intel.c
                   |                            |om

--- Comment #15 from Mathias Nyman (mathias.nyman@linux.intel.com) ---
So xhci interrupt handler does not get called when it should.

The debugfs dump and xhci dynamic debug dmesg show that the controller handled
all events, even completed the control transfer that the driver assumed timed
out, and thus cancelled. Event ring shows all the events:

0x00000000ffffd5d0: TRB 00000000ffffe020 status 'Success' len 0 slot 1 ep 0
type 'Command Completion Event' flags e:C

0x00000000ffffd5e0: TRB 0000000001000000 status 'Success' len 0 slot 0 ep 0
type 'Port Status Change Event' flags e:C

0x00000000ffffd5f0: TRB 00000000ffff5980 status 'Success' len 0 slot 1 ep 1
type 'Transfer Event' flags e:C

0x00000000ffffd600: TRB 00000000ffff5990 status 'Stopped - Length Invalid' len
0 slot 1 ep 1 type 'Transfer Event' flags e:C

0x00000000ffffd610: TRB 00000000ffffe000 status 'Success' len 0 slot 1 ep 0
type 'Command Completion Event' flags e:C
 0 0x00000000ffffd620: type 'UNKNOWN' -> raw 00000000 00000000 00000000
00000000

at event ring address 0ffffd5f0 we see the successful completion of a transfer
ending at 0xffff5980, This would be the control transfer that dmesg shows
driver cancelled due to timeout. control transfer are 2-3 TRBs long, so
starting at 0xffff5960 and end at 0xffff5980.


[  +4.026739] xhci_hcd 0000:c4:00.4: Cancel URB 000000003faffdb9, dev 1, ep
0x0, starting at offset 0xffff5960

debugfs shows that event ring dequeue is at x00000000ffffd5e0, meaning this is
the
last event the driver is aware of.

So xhci interrupt handler was not called for some reason even if xHC handled
all events, and USBSTS register EINT bit indicates xHC tried to inform of the
pending unhandled events.

Only xHCI side issue I can think of is that xhci driver for some odd reason
turned off interrupt generation by clearing USBCMD register INTE bit. Otherwise
I would look at PCI MSI/MSIX generation, or if something is preventing
interrupts on this cpu

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.