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
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.