[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 #38 from Michał Pecio (michal.pecio@gmail.com) ---
Could it be that your sleep is too short and the loop runs faster than any real
world software typically does? What if you increase it to 0.2, 0.5 or 1?

It's theoretically possible that the crash happens when the xHC is resumed too
quickly after being suspended. Maybe it doesn't matter how long we keep it
awake, until this duration is so long that immediately after suspending some
userspace loop enters another iteration and resumes it back.

This *could* explain why the regression happened and why reducing time to
suspend from 200 to 120ms helped somewhat. In such case, we only need to get
this down enough to stop crashes with real world software. The underlying bug
is still there and you will always be able to trigger it with a particularly
chosen loop.

The only fully reliable workaround would be to characterize how long the xHC
must stay asleep to reliably resume and add in-kernel timeouts to enforce this
limit, no matter what userspace (or kernel USB drivers) are trying to do.

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

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