On 21.03.2016 06:18, Rajesh Bhagat wrote:
Hi
I think clearing the whole command ring is a bit too much in this case.
It may cause issues for all attached devices when one command times out.
Hi Mathias,
I understand your point, But I want to understand how would completion handler
be called
if a command is timed out and xhci_abort_cmd_ring is successful. In this case
all the code
would be waiting on completion handler forever.
2. xhci_handle_command_timeout -> xhci_abort_cmd_ring(failure) ->
xhci_cleanup_command_queue -> xhci_complete_del_and_free_cmd
In our case command is timed out, Hence we hit the case #2 but
xhci_abort_cmd_ring is success which
does not calls complete.
xhci_abort_cmd_ring() will write CA bit (CMD_RING_ABORT) to CRCR register.
This will generate a command completion event with status "command aborted" for
the pending command.
This event is then followed by a "command ring stopped" command completion
event.
See xHCI specs 5.4.5 and 4.6.1.2
handle_cmd_completion() will check if cmd_comp_code == COMP_CMD_ABORT, goto
event_handled, and call
xhci_complete_del_and_free_cmd(cmd, cmd_comp_code) for the aborted command.
If xHCI already processed the aborted command, we might only get a command ring
stopped event, in this
case handle_cmd_completion() will call xhci_handle_stopped_cmd_ring(xhci, cmd),
which will turn the
commands that were tagged for "abort" that still remain on the command ring to
NO-OP commands.
The completion callback will be called for these NO-OP command later when we
get a command completion event
for them.
What kernel version, and what xhci vendor was this triggered on?
We are using 4.1.8 kernel
Are you able to try a more recent version?
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
