[Bug 221103] xhci_hcd: System lockup under CPU load during usbfs polling of USB devices on AMD platforms

[bugzilla-daemon@kernel.org]

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

--- Comment #18 from Michał Pecio (michal.pecio@gmail.com) ---
My test got to almost 30k iterations with suspend-resume cycles, no crashes. I
loaded the CPUs with simple "while (1);" on each core.

It seems the problem may be caused by a failure to resume the HC. The driver
should handle it, but something goes wrong. I hoped it would be a stupid null
pointer dereference and netconsole would give us stack trace, but no luck
apparently. I tried crashing my system with SysRq-C and netconsole (over a PCIe
Ethernet NIC) delivered the panic message just fine, so not sure what happens
here.

Could you enable dynamic debug and check if simply toggling power/control
between 'on' and 'auto' produces the same xhci_suspend/xhci_resume messages?
Would this be enough to hang the system, or is it necessary that somebody waits
for the HC to resume to perform some operations on the root hub? Maybe it's
just lack of necessary checks for dead HC somewhere.

What's the state of power/control for those HCs which aren't causing problems?
Are they also getting resumed and suspended under your test, but without
crashing? That would be at least one optimistic result in this whole mess :)

There is another bug 221073 about some AMD HCs dying on resume from system
sleep, may be related. So far nobody knows why it happens.

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

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