Bug 208911

I just got 5.8.1 kernel and get a similar message:
xhci_hcd 0000:02:00.0: FW has invalid version :8209
xhci_hcd 0000:02:00.0: Direct firmware load for renesas_usb_fw.mem failed with error -2
xhci_hcd 0000:02:00.0: request_firmware failed: -2
xhci_hcd: probe of 0000:02:00.0 failed with error -2

I suspect the there are quite a few cards with different firmware on them. I'm compiling a kernel to see if adding my version to the valid rom list works.

Created attachment 290917 [details]
Treat 0x2020 as valid firmware version

Please test with this patch, this will treat 0x2020 as valid firmware verison

For mine, I already figured out that I had to use:

#define ROM_VALID_03 0x2011

Working fine for the past 12 hrs.

(In reply to Antoine Kurukchi from comment #3)
> For mine, I already figured out that I had to use:
> 
> #define ROM_VALID_03 0x2011
> 
> Working fine for the past 12 hrs.

Great patch sent to greg
https://lore.kernel.org/lkml/20200816094949.349878-1-vkoul@kernel.org/

Sorry, please note my firmware version is different. Should I open a new ticket?

(In reply to Antoine Kurukchi from comment #5)
> Sorry, please note my firmware version is different. Should I open a new
> ticket?
Sorry I missed that we have another one (0x2011), let me update that as well.
No need for another ticket :)

(In reply to Antoine Kurukchi from comment #5)
> Sorry, please note my firmware version is different. Should I open a new
> ticket?

I have posted v2 now which adds 0x2011 as well

https://lore.kernel.org/lkml/20200816115950.400594-1-vkoul@kernel.org/

I get the same error with :8215. Is this related?

Kernel version: 5.8.1-arch1-1


system journal (happens before cryptsetup):

    Aug 17 12:31:33 archlinux kernel: xhci_hcd 0000:03:00.0: FW has invalid version :8215
    Aug 17 12:31:33 archlinux kernel: xhci_hcd 0000:03:00.0: Direct firmware load for renesas_usb_fw.mem failed with error -2
    Aug 17 12:31:33 archlinux kernel: xhci_hcd 0000:03:00.0: request_firmware failed: -2
    Aug 17 12:31:33 archlinux kernel: xhci_hcd: probe of 0000:03:00.0 failed with error -2

The USB3 controller is on the mainboard of a Samsung Series 9 Ultrabook NP900X4D

    # lspci -vv -s 03:0.0
    03:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02) (prog-if 30 [XHCI])
        Subsystem: Samsung Electronics Co Ltd Device c0cd
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at f0500000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: [50] Power Management version 3
            Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
            Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
            Address: 0000000000000000  Data: 0000
        Capabilities: [90] MSI-X: Enable- Count=8 Masked-
            Vector table: BAR=0 offset=00001000
            PBA: BAR=0 offset=00001080
        Capabilities: [a0] Express (v2) Endpoint, MSI 00
            DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
                ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
            DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
                RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                MaxPayload 128 bytes, MaxReadReq 512 bytes
            DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend-
            LnkCap:	Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 unlimited
                ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
            LnkCtl:	ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
                ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
            LnkSta:	Speed 5GT/s (ok), Width x1 (ok)
                TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
            DevCap2: Completion Timeout: Not Supported, TimeoutDis+ NROPrPrP- LTR+
                10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix-
                EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
                FRS- TPHComp- ExtTPHComp-
                AtomicOpsCap: 32bit- 64bit- 128bitCAS-
            DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled,
                AtomicOpsCtl: ReqEn-
            LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
                Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                Compliance De-emphasis: -6dB
            LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1-
                EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
                Retimer- 2Retimers- CrosslinkRes: unsupported
        Capabilities: [100 v1] Advanced Error Reporting
            UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
            UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
            UESvrt:	DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
            CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
            CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
            AERCap:	First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn-
                MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
            HeaderLog: 00000000 00000000 00000000 00000000
        Capabilities: [150 v1] Latency Tolerance Reporting
            Max snoop latency: 0ns
            Max no snoop latency: 0ns
        Kernel modules: xhci_pci



I am currently booting into LTS kernel as workaround.

(In reply to Ben Greiner from comment #8)
> I get the same error with :8215. Is this related?

Yes it is..

Okay I am giving up on the versions! had no clue that there are so many versions in the wild!. I will send an updated patch and remove the version check, that should make everyone happy

Sent v3 for this now, removing all the checks!

https://lore.kernel.org/lkml/20200818071739.789720-1-vkoul@kernel.org/

Also noticed this line when updating initramfs. Is this related?

==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: 5.8.1-arch1-1
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [keyboard]
==> WARNING: Possibly missing firmware for module: xhci_pci
  -> Running build hook: [keymap]
  -> Running build hook: [modconf]
  -> Running build hook: [block]

@DocMAX you can just ignore the missing firmware WARNING, because a kernel module has information on the firmware blobs it may need, and mkinitcpio checks this.

(In reply to Vinod Koul from comment #10)
> Sent v3 for this now, removing all the checks!
> 
> https://lore.kernel.org/lkml/20200818071739.789720-1-vkoul@kernel.org/

Patch has been picked as fix in USB tree and will be ported to Stable as well

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-linus&id=d66a57be2f9a315fc10d0f524f670fec903e0fb4

Hello,

I am not trying to waste anyone's time here.  This is what I had:

[    1.578294] xhci_hcd 0000:0a:00.0: FW has invalid version :8215
[    1.578331] xhci_hcd 0000:0a:00.0: Direct firmware load for renesas_usb_fw.mem failed with error -2
[    1.578334] xhci_hcd 0000:0a:00.0: request_firmware failed: -2
[    1.578339] xhci_hcd: probe of 0000:0a:00.0 failed with error -2

I can find a ton of detail about this, I never knew that cards like this needed firmware to be loaded on every boot.  I know FreeBSD will load firmware into LSI Raid cards IIRC.  So it looks like from the comment of the final patch:  "Test if ROM is present and loaded, if so we can skip everything" that my card is going to use the firmware that is in the EEPROM.

I never knew you could load firmware into a USB 3.0 card like this.  It looks like someone has even created a userspace util + SystemD setup for this:  

*https://mjott.de/blog/881-renesas-usb-3-0-controllers-vs-linux/
*https://github.com/markusj/upd72020x-load
*https://lore.kernel.org/patchwork/patch/686290/

So to get to my point.  I have noticed I have some issues sometimes with my Renesas USB card manufactured by StarTech.  Just standard USB stuff, and issues with pluggable USB 3.0 hubs...sometimes I have to reboot to get everything working again, or reset the hub.

Am I doing myself a disservice not upgrading the firmware on it using the Windows utils from Startech...or should I systemd with the github stuff above, and upgrade the firmware every boot?

I don't know much about this stuff, but should linux always push a new firmware to the card like CPU microcode, or FreeBSD.

Like I said, sorry if this is a waste of time or I am posting in the wrong place, but it would be doing linux a disservice if all the Windows drivers pushed newer better firmware to these devices, and worked better, because firmware loading was just skipped.

Anyone have any idea?

Hi, I understand from #9 that the check will be removed. To corroborate that decision, here is another data point with a still different FW version:

[    1.318773] xhci_hcd 0000:02:00.0: FW has invalid version :8228
[    1.318795] xhci_hcd 0000:02:00.0: Direct firmware load for renesas_usb_fw.mem failed with error -2
[    1.318796] xhci_hcd 0000:02:00.0: request_firmware failed: -2
[    1.318799] xhci_hcd: probe of 0000:02:00.0 failed with error -2

Thanks for promptly working on this bug!

The check has been removed and accepted upstream
It should find its way into 5.8 kernel as well once distros roll out updates

If someone has time can they tell me how to track this patch to the linux version it was released in?  I try following the git commits but I have no idea how to figure out, how to track this into an actual release.

I get it now.  I can even find it on the website now.  The title of it:  usb: renesas-xhci: remove version check and then I can find it in the log:  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-5.8.y&ofs=200.

It was released in 5.8.6

Will this fix only came in 5.8 or also in 4.19 (LTS), which is used by Debian 10?

On Sun, Sep 20, 2020 at 09:38:10PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=208911
> 
> Max (kernel@maximilian-stieg.de) changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |kernel@maximilian-stieg.de
> 
> --- Comment #19 from Max (kernel@maximilian-stieg.de) ---
> Will this fix only came in 5.8 or also in 4.19 (LTS), which is used by Debian
> 10?

Does it affect you on the latest 4.19.y kernel release?

Since Debian changed the kernel from 4.9 to 4.19 I can't use the Renesas uPD720201 USB 3.0 card. The devices will only detected, if there plugged-in on the boot. If I unplugged and plugged them in again, they doesn't show up on lsblk. The card will be shown in lspic "04:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)".

It looks it is fixed now?
I did this steps:

- Update the BISO for my hp gen8 microserver to 2.75 (Aug 2020)
- Update to kernel 4.19.0-10
- Restart
And now my usb 3.0 devices will show up.

I'm sorry, but thanks for your time

(In reply to Greg Kroah-Hartman from comment #20)
> On Sun, Sep 20, 2020 at 09:38:10PM +0000,
> bugzilla-daemon@bugzilla.kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=208911
> > 
> > Max (kernel@maximilian-stieg.de) changed:
> > 
> >            What    |Removed                     |Added
> >
> ----------------------------------------------------------------------------
> >                  CC|                            |kernel@maximilian-stieg.de
> > 
> > --- Comment #19 from Max (kernel@maximilian-stieg.de) ---
> > Will this fix only came in 5.8 or also in 4.19 (LTS), which is used by
> Debian
> > 10?
> 
> Does it affect you on the latest 4.19.y kernel release?

Nope it does not affect 4.19 kernel. The change went 5.8 kernel, already has been ported to 5.8 stable kernels

FYI.  I am on 5.8.13-arch1-1 today, and so far so good.