On 15 February 2018 at 19:29, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: > [+ Ard, who helped me chasing the initial issue] > > On 15/02/18 06:43, Bockholdt Arne wrote: >> Hi all, >> >> on our Intel Atom C2578 server with a SuperMicro A1SAi board and a >> Renesas uPD720201 USB 3.0 host controller the controller has stopped >> working since kernel 4.13.x. Before that kernel the dmesg messages from >> XHCI were: >> >> dmesg-4.12.1-serverv4.log:xhci_hcd 0000:03:00.0: xHCI Host Controller >> dmesg-4.12.1-serverv4.log:xhci_hcd 0000:03:00.0: new USB bus registered, >> assigned bus number 2 >> dmesg-4.12.1-serverv4.log:xhci_hcd 0000:03:00.0: hcc params 0x014051cf >> hci version 0x100 quirks 0x00000010 >> dmesg-4.12.1-serverv4.log:usb usb2: Manufacturer: Linux 4.12.1-serverv4 >> xhci-hcd >> dmesg-4.12.1-serverv4.log:xhci_hcd 0000:03:00.0: xHCI Host Controller >> dmesg-4.12.1-serverv4.log:xhci_hcd 0000:03:00.0: new USB bus registered, >> assigned bus number 3 >> dmesg-4.12.1-serverv4.log:usb usb3: Manufacturer: Linux 4.12.1-serverv4 >> xhci-hcd >> >> After that the message look like that: >> >> dmesg-4.13.1-serverv4.log:xhci_hcd 0000:03:00.0: Resetting >> dmesg-4.13.1-serverv4.log:xhci_hcd 0000:03:00.0: Refused to change power >> state, currently in D3 >> dmesg-4.13.1-serverv4.log:xhci_hcd 0000:03:00.0: xHCI Host Controller >> dmesg-4.13.1-serverv4.log:xhci_hcd 0000:03:00.0: new USB bus registered, >> assigned bus number 2 >> dmesg-4.13.1-serverv4.log:xhci_hcd 0000:03:00.0: Host halt failed, -19 >> dmesg-4.13.1-serverv4.log:xhci_hcd 0000:03:00.0: can't setup: -19 >> dmesg-4.13.1-serverv4.log:xhci_hcd 0000:03:00.0: USB bus 2 deregistered >> dmesg-4.13.1-serverv4.log:xhci_hcd 0000:03:00.0: init 0000:03:00.0 fail, -19 >> >> I've tested it with 4.15.3 too, it's still the same. I've narrowed it >> down to the following patch: >> >> commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 >> Author: Marc Zyngier <marc.zyngier@xxxxxxx <mailto:marc.zyngier@xxxxxxx>> >> Date: Tue Aug 1 20:11:08 2017 -0500 >> >> xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue >> >> Reverting the patch on top of 4.15.3 restores the USB3 functionality on >> our server. Please let me know if there is anything I can do to fix the >> problem. Thank you. > Hi Arne, > > This looks pretty bad. I suspect that once reset, the firmware is lost. > I'll try to write a patch dumping some information about it. > > Ard: Do you know if the Cello board has a SPI flash connected to the > Renesas chip, from which it would load the firmware? > No. The system firmware includes a firmware image for the Renesas, and uploads it via the PCIe config space before attaching the ordinary xhci pci driver. https://lists.01.org/pipermail/edk2-devel/2017-April/010013.html This is actually rather annoying, because we cannot distribute the firmware image itself, so rebuilding the firmware from source involves finding your own copy. > Another possibility is that power management kicks in, and that the > endpoint is stuck there. Could also be firmware related, but not only. > I'd welcome any idea on the subject, as I cannot reproduce this issue on > the HW I have. > > It we cannot work out what exactly is causing this, we may have to > default to not resetting the part and rely on a command-line option to > do it... I can't say I'm a fan. > Given that the Cello implementation does not have non-volatile storage either, and the fact that the firmware upload occurs only once, my suspicion is that something else is going on here. -- 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
