https://bugzilla.kernel.org/show_bug.cgi?id=219532 --- Comment #7 from Michał Pecio (michal.pecio@xxxxxxxxx) --- No sensible way to handle it and it should never happen. All we could do is print an error and return immediately, but in any such case the xHCI driver is likely already FUBAR anyway. I *hope* that you are mistaken and your crash was caused by dereferencing xhci->current_cmd in the next line, due to cur_cmd being NULL. This is not supposed to happen either, because the check for (xhci->cmd_ring->dequeue != xhci->cmd_ring->enqueue) is there exactly to catch cases when no commands are pending and cur_cmd is expected to be NULL. But it doesn't work for one in 255 commands, namely when the aborted command was the last one in its ring segment. Then enqueue points at the subsequent link TRB, while dequeue is already in the next segment. Until recently, such command abort would have failed due to a different bug (and caused different problems), but that other bug has just been fixed and it looks like we may start seeing those NULL dereferences now. This patch should keep your system from crashing *if* this is the problem that you are running into. The driver should print "cur_cmd bug detected, 0 fff" and continue working normally. (Which means, keep printing more of those "setup device timed out".) -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
