[bugzilla-daemon@xxxxxxxxxxxxxxxxxxx: [Bug 197159] New: Xhci host controller not responding starting kernel 4.13]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[+cc linux-pci, linux-usb, Mason, Mathias, Lukas, Greg, Felipe, Alan]

----- Forwarded message from bugzilla-daemon@xxxxxxxxxxxxxxxxxxx -----
> 
> Date: Sun, 08 Oct 2017 13:28:13 +0000
> From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
> To: bugzilla.pci@xxxxxxxxx
> Subject: [Bug 197159] New: Xhci host controller not responding starting kernel
> 	4.13
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=197159
> 
>             Bug ID: 197159
>            Summary: Xhci host controller not responding starting kernel
>                     4.13
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 4.13
>           Hardware: Intel
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: blocking
>           Priority: P1
>          Component: PCI
>           Assignee: drivers_pci@xxxxxxxxxxxxxxxxxxxx
>           Reporter: niklas@xxxxxxxxxxxxxxx
>         Regression: No
> 
> When booting with a Expresscard USB 3.0 adapter (NEC UPD720202 Chip), the
> following error is generated:
> 
> "xhci_hcd 0000:05:00.0: xHCI host controller not responding, assumed dead"
> 
> This card still works fine with kernel 4.9.

Thanks very much for the bug report, and sorry for the regression.

Can you please collect the complete dmesg log and "lspci -vv" output
and attach them to the bugzilla?

> Additionally, for some reason this also interferes with LUKS on an LVM
> partition; password does not work and computer becomes stuck at this point.
> This works as normal if card is removed and computer is rebooted.
> 
> Can we please have Expresscard USB 3.0 functionality back in the kernel?
> 
> This problem has been described elsewhere, but couldn't find any kernel bug
> report for it. See this link for further information:
> 
> http://patchwork.ozlabs.org/patch/804867/

In that thread, Mason reported a regression that looks similar, but as
far as I can tell, we never identified a root cause.

  1) The problem Mason reported was on a Tango platform, which has a
     known hardware issue that corrupts data when simultaneous config
     and MMIO accesses occur.  You're seeing the problem on a
     different platform, which is very helpful.

  2) Mathias suggested d9f11ba9f107 ("xhci: Rework how we handle
     unresponsive or hoptlug removed hosts"), which appeared in
     v4.12-rc1, as a possible culprit, but I don't see a bisection
     that definitively identifies this commit.

     Is it possible for you to test both fe190ed0d602 ("xhci: Do not
     halt the host until both HCD have disconnected their devices.")
     and d9f11ba9f107 ("xhci: Rework how we handle unresponsive or
     hoptlug removed hosts") so we can tell for sure whether
     d9f11ba9f107 broke it?

  3) Mason did report:
       v4.11.12 OK
       v4.12-rc1 KO
     I assume "KO" means broken (unless that's a typo for "OK"?).  If
     it means "broken", he did at least confirm that the problem first
     appeared in v4.12-rc1.

Bjorn

> Tested with Antergos (Arch) on a Thinkpad T420. The card works with the LTS
> kernel which is at 4.9.52-1 but not the latest which is 4.13.3-1.



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux