Re: [RFC/PATCH] usb/xhci: avoid kernel panic on xhci_suspend()

[Greg KH]

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Wed, Jan 08, 2014 at 03:49:07AM +0000, Tang, Jianqiang wrote:
> Hi,
>  1) I met this issue one time just boot up our Linux Platform(Kernel3.10) with XHCI driver, then kernel panic happen.
> 
>    And this issue reported once by other internal team.
> 
>    Nothing special of reproduce step and do not need special Hardware I think.
> 
>    Just random issue which will happen when meet the timing condition.
> 
>  2) This issue is introduced by this patch:
> 
>      https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=596d789a211d134dc5f94d1e5957248c204ef850
> 
>    which set all hub autosuspend delay to 0.

That patch was released in a kernel almost a full year ago, yet we have
never had a report of this happening before, so are you sure this patch
is the root cause?

>    This causes race condition during XHCI driver initialization,
> 
>     After USB2 hcd and USB2 root hub finish the initialization, USB2 root hub is functional and auto suspend right now, hence trigger XHCI runtime suspend flow;
> 
>     At the same time, XHCI driver continue to initialize the USB3 hcd and assign to xhci->shared_hcd after finish the initialization;
>     
>     Since xhci_suspend() use the xhci->shared_hcd, so there is race condition that when XHCI runtime suspend called, xhci->shared_hcd still NULL.
> 
>     I think this patch is a fix solution since before XHCI finish the whole initialization, USB2 root hub triggered runtime suspend is mean less and do not need to handle.

With this patch applied, does the crash go away?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/