Bug 208911 - Renesas USB controller - FW has invalid version :8224
Summary: Renesas USB controller - FW has invalid version :8224
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Default virtual assignee for Drivers/USB
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-15 07:13 UTC by DocMAX
Modified: 2020-10-05 16:42 UTC (History)
7 users (show)

See Also:
Kernel Version: Linux t420 5.8.1-arch1-1 #1 SMP PREEMPT Wed, 12 Aug 2020 18:50:43 +0000 x86_64 GNU/Linux
Tree: Mainline
Regression: No


Attachments
Treat 0x2020 as valid firmware version (1.10 KB, patch)
2020-08-16 05:49 UTC, Vinod Koul
Details | Diff

Description DocMAX 2020-08-15 07:13:08 UTC
Since Kernel 5.8 i get this error:

Aug 15 08:33:25 t420 kernel: xhci_hcd 0000:05:00.0: FW has invalid version :8224
Aug 15 08:33:25 t420 kernel: xhci_hcd 0000:05:00.0: request_firmware failed: -2
Comment 1 Antoine Kurukchi 2020-08-15 17:06:57 UTC
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.
Comment 2 Vinod Koul 2020-08-16 05:49:45 UTC
Created attachment 290917 [details]
Treat 0x2020 as valid firmware version

Please test with this patch, this will treat 0x2020 as valid firmware verison
Comment 3 Antoine Kurukchi 2020-08-16 09:38:47 UTC
For mine, I already figured out that I had to use:

#define ROM_VALID_03 0x2011

Working fine for the past 12 hrs.
Comment 4 Vinod Koul 2020-08-16 09:51:15 UTC
(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/
Comment 5 Antoine Kurukchi 2020-08-16 10:02:48 UTC
Sorry, please note my firmware version is different. Should I open a new ticket?
Comment 6 Vinod Koul 2020-08-16 11:48:42 UTC
(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 :)
Comment 7 Vinod Koul 2020-08-16 12:03:38 UTC
(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/
Comment 8 Ben Greiner 2020-08-17 10:55:23 UTC
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.
Comment 9 Vinod Koul 2020-08-18 06:41:35 UTC
(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
Comment 10 Vinod Koul 2020-08-18 07:19:38 UTC
Sent v3 for this now, removing all the checks!

https://lore.kernel.org/lkml/20200818071739.789720-1-vkoul@kernel.org/
Comment 11 DocMAX 2020-08-20 07:14:37 UTC
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]
Comment 12 Iru Cai 2020-08-21 02:15:26 UTC
@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.
Comment 13 Vinod Koul 2020-08-21 05:34:36 UTC
(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
Comment 14 neoweb 2020-08-21 22:05:17 UTC
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?
Comment 15 Christian 2020-08-31 08:19:32 UTC
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!
Comment 16 Vinod Koul 2020-09-01 05:58:15 UTC
The check has been removed and accepted upstream
It should find its way into 5.8 kernel as well once distros roll out updates
Comment 17 neoweb 2020-09-16 20:14:17 UTC
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.
Comment 18 neoweb 2020-09-16 21:13:01 UTC
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
Comment 19 Max 2020-09-20 21:38:10 UTC
Will this fix only came in 5.8 or also in 4.19 (LTS), which is used by Debian 10?
Comment 20 Greg Kroah-Hartman 2020-09-21 05:05:15 UTC
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?
Comment 21 Max 2020-09-21 07:26:18 UTC
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
Comment 22 Vinod Koul 2020-09-22 04:05:35 UTC
(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
Comment 23 neoweb 2020-10-05 16:42:55 UTC
FYI.  I am on 5.8.13-arch1-1 today, and so far so good.

Note You need to log in before you can comment on or make changes to this bug.