RPi 4 2 GB losing USB - Firmware issue?

camelreef · February 1, 2022 at 1:05 PM

Hello,

Using nightly-20220131-71f8aac (same issue with nightly-20220130, though) on a RPi 4 2GB.

Fresh install, sees USB keyboard and USB3 HDD fine. USB firmware version displayed.

One or 2 reboots later, disk and keyboard are gone, USB firmware version is 0000000, saying using bootloader EEPROM.

https://pastebin.ubuntu.com/p/p67hyDpZFN/ (no kodi debug log, though, as I'm thinking that Kodi itself has nothing to do with it, the issue is lower in the stack)

Afresh install fixes, then back to no USB.

Code

BOOTLOADER: up to date
   CURRENT: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
    LATEST: Thu Apr 29 16:11:25 UTC 2021 (1619712685)
   RELEASE: default (/usr/lib/kernel-overlays/base/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 00000000
    LATEST: 00000000

I have other RPis 4 with different hardware revisions (c03111, c03112) not having this problem.

This one is apparently a brand new revision number: b03115

Could this be an issue wrt firmware?

**HiassofT** · February 1, 2022 at 6:46 PM

Somehow you seem to be running an ancient firmware version (start.elf)

Code

Jan 18 11:35:43.585387 LibreELEC kernel: raspberrypi-firmware soc:firmware: Attached to firmware from 2021-09-30T19:21:54, variant start_x

Try a fresh install, this should be 2022-01-06

so long,

Hias

camelreef · February 1, 2022 at 8:27 PM

Quote from HiassofT
Somehow you seem to be running an ancient firmware version (start.elf)
Code
Jan 18 11:35:43.585387 LibreELEC kernel: raspberrypi-firmware soc:firmware: Attached to firmware from 2021-09-30T19:21:54, variant start_x
Try a fresh install, this should be 2022-01-06
so long,
Hias

ah crap, my bad, wrong paste... I had played a bit... Sorry...

A fresh install is what got me in a pickle.

I have a fresh install, never rebooted, so USB is there

Code

[    0.053470] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-01-06T15:40:20, variant start_x
[    0.056806] raspberrypi-firmware soc:firmware: Firmware hash is 58e03c94953762222f2b838390dde54d46c38381

yup... I've rebooted, and the whole USB is gone, empty lsusb and all.

http://ix.io/3Ol5

With this interesting part, probably:

Code

[    1.598710] ------------[ cut here ]------------
[    1.598720] Firmware transaction timeout
[    1.598753] WARNING: CPU: 3 PID: 1 at rpi_firmware_property_list+0x1ec/0x26c
[    1.598771] Modules linked in:
[    1.598778] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.15.13 #1
[    1.598783] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
[    1.598786] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    1.598791] pc : rpi_firmware_property_list+0x1ec/0x26c
[    1.598798] lr : rpi_firmware_property_list+0x1ec/0x26c
[    1.598803] sp : ffffffc011bcb9e0
[    1.598806] x29: ffffffc011bcb9e0 x28: ffffff8040b78780 x27: ffffff804097f7c0
[    1.598815] x26: 0000000000000012 x25: ffffffc01200d008 x24: 0000000000001000
[    1.598823] x23: ffffff804126ec00 x22: ffffffc011a34818 x21: ffffff804097f780
[    1.598831] x20: 000000000000000c x19: ffffffc01200d000 x18: 0000000000000020
[    1.598838] x17: 0000000000000003 x16: 0000000000000003 x15: 60d98d1db030ce1a
[    1.598846] x14: 0176e40dd599d310 x13: 74756f656d697420 x12: 6e6f69746361736e
[    1.598854] x11: 656820747563205b x10: ffffffc0119392d0 x9 : ffffffc0100a7930
[    1.598861] x8 : ffffffc0118e0418 x7 : ffffffc011938418 x6 : 0000000000000eb8
[    1.598868] x5 : 000000000000bff4 x4 : 40000000fffff09d x3 : 0000000000000000
[    1.598876] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff80401a8000
[    1.598884] Call trace:
[    1.598887]  rpi_firmware_property_list+0x1ec/0x26c
[    1.598893]  rpi_firmware_property+0x7c/0x114
[    1.598898]  vc4_drm_bind+0x2a4/0x310
[    1.598905]  try_to_bring_up_master+0x230/0x320
[    1.598911]  component_master_add_with_match+0xbc/0x10c
[    1.598915]  vc4_platform_drm_probe+0xd0/0x110
[    1.598921]  platform_probe+0x74/0xe4
[    1.598926]  really_probe+0xc4/0x46c
[    1.598929]  __driver_probe_device+0x11c/0x190
[    1.598933]  driver_probe_device+0x48/0x110
[    1.598936]  __driver_attach+0xd8/0x1f0
[    1.598940]  bus_for_each_dev+0x7c/0xe0
[    1.598947]  driver_attach+0x30/0x3c
[    1.598950]  bus_add_driver+0x154/0x250
[    1.598956]  driver_register+0x84/0x140
[    1.598960]  __platform_driver_register+0x34/0x40
[    1.598964]  vc4_drm_register+0x40/0x4c
[    1.598972]  do_one_initcall+0x50/0x240
[    1.598977]  kernel_init_freeable+0x29c/0x33c
[    1.598982]  kernel_init+0x30/0x13c
[    1.598987]  ret_from_fork+0x10/0x20
[    1.598995] ---[ end trace de6f803443773dc2 ]---

Display More

Nico

**HiassofT** · February 1, 2022 at 9:10 PM

It looks like the firmware crashed. Can you try with a complete clean install on a separate sd card? Not sure if force_turbo and/or core_freq_min might play a role in that.

Edit: if this doesn't help please also test with latest RPiOS and see if you get the same "Firmware transaction timeout" splat.

so long,

Hias

camelreef · February 1, 2022 at 9:16 PM

Bed time now, but I will try tomorrow without force_turbo and/or core_freq_min and report!

It's a setup that is not in prod right now, I can play with it.

Nico

camelreef · February 2, 2022 at 1:21 PM

OK, I've removed force_turbo and/or core_freq_min and USB is back. If this is the fix atm, I'm fine with it. I'm pretty confident that there won't be any 50/60 Hz content played on this, ever.

I've rebooted the system a few times, it looks solid.

http://ix.io/3Opp

Code

BOOTLOADER: up to date
   CURRENT: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
    LATEST: Thu Apr 29 16:11:25 UTC 2021 (1619712685)
   RELEASE: default (/usr/lib/kernel-overlays/base/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

I'll put the system through the whole workload (there is another machine using the mounted disk over its samba share) and see how it is.

It appears that my remote samba client is still having issues, with the drive mounted from LE dropping out. I've even had LE totally freeze (no GUI, logged-in SSH session, samba transfers, etc...) on me for at least a full minute, before all came back.

Code

Feb 02 13:07:18 grabber kernel: CIFS: VFS: \\10.25.25.2 has not responded in 180 seconds. Reconnecting...
Feb 02 13:07:18 grabber kernel: CIFS: VFS: Send error in read = -512
Feb 02 13:07:18 grabber kernel: CIFS: VFS: Send error in write = -512


Feb 02 13:14:25 grabber kernel: CIFS: VFS: \\10.25.25.2 sends on sock 00000000397075ca stuck for 15 seconds
Feb 02 13:14:25 grabber kernel: CIFS: VFS: \\10.25.25.2 Error -11 sending data on socket to server
Feb 02 13:14:41 grabber kernel: CIFS: VFS: \\10.25.25.2 sends on sock 00000000397075ca stuck for 15 seconds
Feb 02 13:14:41 grabber kernel: CIFS: VFS: \\10.25.25.2 Error -11 sending data on socket to server
Feb 02 13:14:56 grabber kernel: CIFS: VFS: \\10.25.25.2 sends on sock 00000000397075ca stuck for 15 seconds
Feb 02 13:14:56 grabber kernel: CIFS: VFS: \\10.25.25.2 Error -11 sending data on socket to server

Display More

I see this on the LE machine:

Code

Feb 02 13:17:23 kodiplayer smbd[1499]: [2022/02/02 13:17:23.603642,  0] ../../source3/smbd/smb2_read.c:265(smb2_sendfile_send_data)
Feb 02 13:17:23 kodiplayer smbd[1499]:   smb2_sendfile_send_data: sendfile failed for file Transit/blahblahblah (Connection reset by peer) for client ipv4:10.25.25.1:44238. Terminating


Feb 02 13:26:33 kodiplayer smbd[1500]: [2022/02/02 13:26:33.368864,  0] ../../lib/util/fault.c:159(smb_panic_log)
Feb 02 13:26:33 kodiplayer smbd[1500]:   ===============================================================
Feb 02 13:26:33 kodiplayer smbd[1500]: [2022/02/02 13:26:33.368996,  0] ../../lib/util/fault.c:160(smb_panic_log)
Feb 02 13:26:33 kodiplayer smbd[1500]:   INTERNAL ERROR: Signal 11: Segmentation fault in pid 1500 (4.13.16)
Feb 02 13:26:33 kodiplayer smbd[1500]: [2022/02/02 13:26:33.369060,  0] ../../lib/util/fault.c:164(smb_panic_log)
Feb 02 13:26:33 kodiplayer smbd[1500]:   If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting
Feb 02 13:26:33 kodiplayer smbd[1500]: [2022/02/02 13:26:33.369122,  0] ../../lib/util/fault.c:169(smb_panic_log)
Feb 02 13:26:33 kodiplayer smbd[1500]:   ===============================================================
Feb 02 13:26:33 kodiplayer smbd[1500]: [2022/02/02 13:26:33.369200,  0] ../../lib/util/fault.c:170(smb_panic_log)
Feb 02 13:26:33 kodiplayer smbd[1500]:   PANIC (pid 1500): Signal 11: Segmentation fault in 4.13.16
Feb 02 13:26:33 kodiplayer smbd[1500]: [2022/02/02 13:26:33.369445,  0] ../../lib/util/fault.c:232(log_stack_trace)
Feb 02 13:26:33 kodiplayer smbd[1500]:   BACKTRACE:
Feb 02 13:26:33 kodiplayer smbd[1500]:    #0 log_stack_trace + 0x7c [ip=0xf7852dec] [sp=0xff97e2c0]
Feb 02 13:26:33 kodiplayer smbd[1500]: [2022/02/02 13:26:33.392114,  0] ../../source3/lib/dumpcore.c:283(dump_core)
Feb 02 13:26:33 kodiplayer smbd[1500]:   Exiting on internal error (core file administratively disabled)

Display More

http://ix.io/3Oqv

I am now doing a test from my client mounting a volume from my NAS. I doesn't hurt checking that the client is not the problem... (though I have other setups in production configured in exactly the same way that are working perfectly fine)

Nico

camelreef · February 2, 2022 at 2:13 PM

Using the same client, doing exactly the same thing, under the same load, but using my NAS as a samba server and not the LE box, I have no issue, things are stable.

This points more and more to that Pi4 with a brand new hardware revision having a problem.

My next step is to take my SD card and stick it into another Pi 4 I have handy, an older hardware revision, and see if it is stable.

camelreef · February 2, 2022 at 4:02 PM

erm... Nope... Same issue with an older Pi 4 hardware revision...

Has anything changed re. Samba recently or should I focus on the client?

I have an exact replica of this setup running LE nightly-20220120-f7f2fd5 without any issue.

I went back to nightly-20220125-ce61477 on the non prod setup, but same issue.

I'm guessing that a test using the release LE10 would tell me.

camelreef · February 2, 2022 at 6:10 PM

you know what?

Let's stick to the config.txt options crashing the firmware.

The samba stuff is probably from the DietPi on the other machine... I'm reinstalling it fresh and will see...

**HiassofT** · February 2, 2022 at 7:08 PM

Not really sure. There's been a recent firmware change affecting clocks https://github.com/raspberrypi/fi…70f31a98167eef6 - I plan to update kernel+firmware in LE later this week, so might be worth giving it a try after that.

It could also be that the silicon in the RPi4 is marginal - a small overvoltage in config.txt might help.

Also please test with RPiOS and latest rpi-update kernel.

so long,

Hias

camelreef · February 2, 2022 at 7:11 PM

Quote from HiassofT

Not really sure. There's been a recent firmware change affecting clocks https://github.com/raspberrypi/fi…70f31a98167eef6 - I plan to update kernel+firmware in LE later this week, so might be worth giving it a try after that.
It could also be that the silicon in the RPi4 is marginal - a small overvoltage in config.txt might help.
Also please test with RPiOS and latest rpi-update kernel.
so long,
Hias

will do tomorrow. I need to unglue myself from that system and rejoin family life this evening!

Thanks for your usual help and patience.

Nico

ghtester · February 2, 2022 at 7:19 PM

Quote from camelreef

This one is apparently a brand new revision number: b03115

I am afraid that could be a reason... Looks it's too new and there are several different (not LE related) issues yet reported with this HW release. It will take some time.

camelreef · February 3, 2022 at 10:09 AM

Quote from HiassofT

It could also be that the silicon in the RPi4 is marginal - a small overvoltage in config.txt might help.

over_voltage=1 breaks tons!

http://ix.io/3OvR

Kodi does start, the disk is not mounted, dmesg is full of errors...

That hw revision appears to be a tad problematic...

Code

Hardware	: BCM2835
Revision	: b03115
Serial		: 10000000b7f3ee23
Model		: Raspberry Pi 4 Model B Rev 1.5

Nico

frakkin64 · February 3, 2022 at 12:05 PM

Have you tested it with Raspberry Pi OS, minimal USB configuration (no external hub), then start adding devices in, and perhaps report the issue to https://github.com/raspberrypi/linux/ (they prefer testing on Raspberry Pi OS, but have been known to look into other OS issues, really depends). Once you have Raspberry Pi OS up then you will probably want to use rpi-update to test the next branch (5.15). The external hub & hard drive is questionable, whether if it is over-drawing current from the USB ports (design maximum is 1.2 amps from all USB ports from what I read). It could be your power adapter as well.

I would be surprised if it is a hardware revision issue, at this point the hardware revisions should be fairly minor and well tested, opening that issue and putting your speculation into the issue may reveal what the hardware change was and what the engineers think about that theory. It is likely an issue with the 5.15 kernel. If you were getting flip timeouts/drm related issues earlier when the firmware timed out then it wouldn't surprise me, because those seem to cause kernel soft-lockups/deadlocks. It seems like your earlier splat is from VC4 DRM.

Perhaps the kernel push that HiassofT referred to will help, he pushed the PR yesterday so it may show up in the nightly soon.

camelreef · February 3, 2022 at 12:21 PM

Quote from frakkin64

Have you tested it with Raspberry Pi OS, minimal USB configuration (no external hub), then start adding devices in, and perhaps report the issue to https://github.com/raspberrypi/linux/ (they prefer testing on Raspberry Pi OS, but have been known to look into other OS issues, really depends). Once you have Raspberry Pi OS up then you will probably want to use rpi-update to test the next branch (5.15). The external hub & hard drive is questionable, whether if it is over-drawing current from the USB ports (design maximum is 1.2 amps from all USB ports from what I read). It could be your power adapter as well.
I would be surprised if it is a hardware revision issue, at this point the hardware revisions should be fairly minor and well tested, opening that issue and putting your speculation into the issue may reveal what the hardware change was and what the engineers think about that theory. It is likely an issue with the 5.15 kernel. If you were getting flip timeouts/drm related issues earlier when the firmware timed out then it wouldn't surprise me, because those seem to cause kernel soft-lockups/deadlocks. It seems like your earlier splat is from VC4 DRM.
Perhaps the kernel push that HiassofT referred to will help, he pushed the PR yesterday so it may show up in the nightly soon.

No hub was ever involved, the HDD is plugged straight into the Pi. I've had the same HDD into a Pi 4 in other setups like that without issue.

The power adapter is a brand new official one. I could try another one I have in stock, eventually. I never had a lightning bolt on the screen.

I'm just done setting up a fresh Raspberry Pi OS with a full upgrade, with Samba sharing my drive.

Code

Linux kodiplayer 5.10.92-v8+ #1514 SMP PREEMPT Mon Jan 17 17:39:38 GMT 2022 aarch64 GNU/Linux


BOOTLOADER: up to date
   CURRENT: Tue 25 Jan 14:30:41 UTC 2022 (1643121041)
    LATEST: Tue 25 Jan 14:30:41 UTC 2022 (1643121041)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.


  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

Display More

I haven't run rpi-update yet.

I'm now running the same workflow and monitoring the logs. so far so good, but I will give it time.

Then I'll update and do the same.

Nico

camelreef · February 3, 2022 at 12:54 PM

Things were running fine with a fresh and normally updated RPi OS, as in the previous message.

So I ran rpi-update, which took me to another 5.10 kernel, not a 5.15, as expected. Firmware also appears to be the same.

Code

pi@kodiplayer:~ $ sudo rpi-update 
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** We're running for the first time
 *** Backing up files (this will take a few minutes)
 *** Backing up firmware
 *** Backing up modules 5.10.92-v8+
#############################################################
WARNING: This update bumps to rpi-5.10.y linux tree
See: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=288234
'rpi-update' should only be used if there is a specific
reason to do so - for example, a request by a Raspberry Pi
engineer or if you want to help the testing effort
and are comfortable with restoring if there are regressions.


DO NOT use 'rpi-update' as part of a regular update process.


##############################################################
Would you like to proceed? (y/N)
 *** Downloading specific firmware revision (this will take a few minutes)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   173  100   173    0     0   2471      0 --:--:-- --:--:-- --:--:--  2471
100  121M  100  121M    0     0  4621k      0  0:00:26  0:00:26 --:--:-- 4443k
 *** Updating firmware
 *** Updating kernel modules
 *** depmod 5.10.95-v8+
 *** depmod 5.10.95+
 *** depmod 5.10.95-v7l+
 *** depmod 5.10.95-v7+
 *** Updating VideoCore libraries
 *** Using SoftFP libraries
 *** Updating SDK
 *** Running ldconfig
 *** Storing current firmware revision
 *** Deleting downloaded files
 *** Syncing changes to disk
 *** If no errors appeared, your firmware was successfully updated to 39821d33e777cde9ba1a3cc8a73cfdd62fbbd2de
 *** A reboot is needed to activate the new firmware


Linux kodiplayer 5.10.95-v8+ #1519 SMP PREEMPT Tue Feb 1 13:19:30 GMT 2022 aarch64 GNU/Linux


BOOTLOADER: up to date
   CURRENT: Tue 25 Jan 14:30:41 UTC 2022 (1643121041)
    LATEST: Tue 25 Jan 14:30:41 UTC 2022 (1643121041)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.


  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

Display More

Should I do this instead?

Code

sudo BRANCH=next rpi-update

or

sudo rpi-update next

camelreef · February 3, 2022 at 1:57 PM

My workflow/workload was running fine on the system gone through the vanilla rpi-update 5.10 kernel.

So I went to the next branch, 5.15 kernel, same firmware.

Code

pi@kodiplayer:~ $ sudo BRANCH=next rpi-update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
##############################################################
WARNING: This update bumps to rpi-5.15.y linux tree
This update will install from the 'next' firmware branch.
See discussions at:
https://forums.raspberrypi.com/viewtopic.php?t=322879
##############################################################
Would you like to proceed? (y/N)
 *** Downloading specific firmware revision (this will take a few minutes)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   173  100   173    0     0   2436      0 --:--:-- --:--:-- --:--:--  2436
100  123M    0  123M    0     0  5986k      0 --:--:--  0:00:21 --:--:-- 7651k
 *** Updating firmware
 *** Updating kernel modules
 *** depmod 5.15.16-v7l+
 *** depmod 5.15.16+
 *** depmod 5.15.16-v8+
 *** depmod 5.15.16-v7+
 *** Updating VideoCore libraries
 *** Using SoftFP libraries
 *** Updating SDK
 *** Running ldconfig
 *** Storing current firmware revision
 *** Deleting downloaded files
 *** Syncing changes to disk
 *** If no errors appeared, your firmware was successfully updated to f939fb3712616496f0369e473187ca6e0b92929b
 *** A reboot is needed to activate the new firmware


Linux kodiplayer 5.15.16-v8+ #1516 SMP PREEMPT Tue Jan 25 13:46:58 GMT 2022 aarch64 GNU/Linux


BOOTLOADER: up to date
   CURRENT: Tue 25 Jan 14:30:41 UTC 2022 (1643121041)
    LATEST: Tue 25 Jan 14:30:41 UTC 2022 (1643121041)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.


  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

Display More

This is also very solid under the same workflow. The remote RPi3 has no issue with the CIFS/Samba mount, it never loses it. all is good in the world.

I would say that this rules out the hardware's marginality, the power adapter, the disk, the network and the client's setup. None of those have changed.

I have the same setup, RPi4, hard drive, network, etc. running elsewhere without issues at all. The only differences are that it's running nightly-20220120-f7f2fd (which I daren't upgrade atm) and it a 1.2 hardware revision.

So... what can I do to help hunt for the issue on LE? Use and abuse me!

I'll start by trying today's nightly (20220203), then I can put the same SD card into a rev. 1.1 Pi 4 that I have access to. That may point at a software change since Jan. 20 if I have the same problem.

Nico

camelreef · February 3, 2022 at 2:45 PM

Rev 1.5 RPi 4 - LE11 nightly-20220203-5347c5e

Code

[    0.110311] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-01-06T15:40:20, variant start_x
[    0.113653] raspberrypi-firmware soc:firmware: Firmware hash is 58e03c94953762222f2b838390dde54d46c38381


BOOTLOADER: up to date
   CURRENT: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
    LATEST: Thu Apr 29 16:11:25 UTC 2021 (1619712685)
   RELEASE: default (/usr/lib/kernel-overlays/base/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1


kodiplayer:~ # ls -lah /usr/lib/kernel-overlays/base/lib/firmware/raspberrypi/bootloader/default/
total 697K   
drwxr-xr-x    2 root     root          92 Feb  2 22:29 .
drwxr-xr-x    5 root     root          86 Feb  2 22:29 ..
-rw-r--r--    1 root     root      512.0K Feb  2 22:29 pieeprom-2021-04-29.bin
-rw-r--r--    1 root     root       87.2K Feb  2 22:29 recovery.bin
-rw-r--r--    1 root     root       96.9K Feb  2 22:29 vl805-000138a1.bin

Display More

And boom!, on the remote machine:

Code

Feb 03 14:16:06 grabber kernel: CIFS: VFS: \\kodiplayer.local sends on sock 000000001aa9464e stuck for 15 seconds
Feb 03 14:16:06 grabber kernel: CIFS: VFS: \\kodiplayer.local Error -11 sending data on socket to server
Feb 03 14:16:09 grabber kernel: CIFS: VFS: Send error in read = -11
Feb 03 14:16:09 grabber kernel: CIFS: VFS: Send error in read = -11
Feb 03 14:16:34 grabber kernel: CIFS: VFS: \\kodiplayer.local sends on sock 00000000807891b4 stuck for 15 seconds
Feb 03 14:16:34 grabber kernel: CIFS: VFS: \\kodiplayer.local Error -11 sending data on socket to server
Feb 03 14:16:50 grabber kernel: CIFS: VFS: \\kodiplayer.local sends on sock 00000000807891b4 stuck for 15 seconds
Feb 03 14:16:50 grabber kernel: CIFS: VFS: \\kodiplayer.local Error -11 sending data on socket to server

IIUC, the RPi OS that worked well was using the Tue 25 Jan 14:30:41 UTC 2022 (1643121041) firmware.

LE11 still uses the Tue Jan 25 14:30:41 UTC 2022 (1643121041) firmware.

Do I need a new nightly to change this, or can I force it on my own quickly?

As ever, thanks for your help!

Nico