On 25.08.2015 22:53, Vincent Pelletier wrote:
On Tue, 25 Aug 2015 21:09:20 +0200, Vincent Pelletier
<plr.vincent@xxxxxxxxx> wrote:
I'm not sure how I'll get this (I have a lot to learn about kernel
debugging).
Answering to myself: log_buf_len kernel parameter.
I sent you my dmesg off-list (335KB raw, 46KB gzipped).
Thanks,
So the Address device command times out, (usb device didn't respond in 5 seconds)
We Abort the address device command.
In the first mail you sent we failed in aborting a command,
and the command ring didn't stop.
In the log you recently sent the command ring stopped,
command was successfully aborted and life went on.
I suppose everything worked fine after this?
The "Command completion event does not match command" in the logs
is a bit misleading, aborting a command is done with a register write,
and will generate a "command completion" event without an existing command.
Anyways, addressing device timeout and failure to stop command ring could well
be because of something is not ready yet, BIOS handover, as you suggested is a good guess.
An obvious xhci bios handoff should print out "xHCI BIOS handoff failed (BIOS bug ?)"
Otherwise only thing I can think of is tuning the how we abort the command ring,
I can create a patch but at the same time I wouldn't have too high hopes for it.
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
