Posts by HarryH

    The behavior with multiple HDMI 1 entries is known to me with SONY Android TVs. There can some more sub devices displayed if you have additional CEC compatible devices connected to your DENON AVR. On that way you are able to switch between the different CEC sources on your AVR via TV remote. Also I can confirm that not all (but the most) CEC keys are working if the TV is only switched to "HDMI 1" and not to the sub entry "HDMI 1 KODI ...". Maybe you have installed a firmware update for the TV, so that something has been changed?

    The TalkBack feature (if available) is disabled? https://www.sony.com/electronics/support/articles/00269974


    Regarding the irritating double entries for the CEC adapter in the input settings menu, you should switch to a newer version than the official version 12.0.1, as this contains the fix: https://test.libreelec.tv/12.0/RPi/RPi5/…-0803b93.img.gz

    Both are non-native Linux file systems. Can you prepare a thumb drive with ext4 and test again? If you have no Linux to fill the stick with content directly, maybe you can copy from your laptop via network to it.

    Note: All file systems on external drives (such as SD cards, USB sticks, etc.) are vulnerable during cached writes, so you should make sure that you do not remove the drive from the running system without taking special measures. For the test with ext4, I would recommend not unplugging the drive until the system has shut down properly.

    I already posted the commands to collect some information. The last 3 lines of my previous post contains the commands to use via SSH console.

    • lsblb -> list block devices
    • lsusb -> list USB devices
    • dmesg ... -> search for specific entries in the kernel message log

    If it sounds like rocket science for you, then we will go beyond the scope of this thread.

    Sorry, if I distracted you. I wanted to make sure that both physical drives are recognized correctly. Because this is important regardless of whether you use 2 individual drives or the spanned volume. But if you have created a spanned volume using the Windows functions, as chewitt has assumed, then you need all the things he has already described to get access to the whole volume.

    There are 2 things to note in your screenshots:

    • You hasn't used the official supported power supply -> recommended: 5.1V / 5A via Power Delivery protocol
      Other PSU can be unstable, because not ready for the fast load switches of the RPi5.
    • The bootloader is one of the first and outdated 2023-10-18 (current: 2024-09-10)

    It's also important to know if you use a case like the Argon ONE V3, because this needs special handling.

    But in general, please follow chewitt recommendation and try a new SD card first.

    If you have a RPi5 in use, please be aware that the gpiochip has been reordered back to gpiochip 0 with kernel version 6.6.45 and following.

    Use gpiochip0 for the user-facing GPIOs on Pi 5 by pelwell · Pull Request #6144 · raspberrypi/linux
    Pi 5 contains multiple GPIO controllers; running gpiodetect shows that there are five. Prior to this patch set, they appear like this: gpiochip0…
    github.com
    lgpio pin factory is broken on RPi5 since kernel 6.6.45 · Issue #1166 · gpiozero/gpiozero
    Operating system: e.g. RPiOS Bookworm Python version: 3.11.2 Pi model: Pi 5 GPIO Zero version: 2.0.1 Pin factory used: lgpio A recent change in the RPi kernel…
    github.com

    Maybe this is the issue for not working with 12.0.1.

    Your configuration looks to me like common practice and in my opinion it normally should work.

    I grabbed this from the known issues part of the GC110 firmware changelog:

    • Loop protection might not work between two Insight-managed switches.
      Workaround: Disable IGMP snooping on at last one the switches.
    • When IGMP snooping or MLD snooping is globally enabled or enabled on a VLAN, unknown multicast packets are dropped for both IPv4 and IPv6 traffic.
      Workaround: Disable both IGMP snooping and MLD snooping.

    If you doesn't have the DHCP L2 Relay / DHCP snooping enabled and accidentally misconfigured, then there seems to be some other "features" available that can be trigger such issues too... ;)

    You are right, my question was not without a troubleshooting background.

    In the past, I had a long term NFS troubleshooting with a network newbie as a communication partner. He was using the SG200-08P managed switch, but he didn't mention it. The network had been producing strange problems. NFS connections were not possible between the satellite receiver and the NAS. We spent ages trying out the settings on both the receiver and the NAS. In the end, I was able to convince him to install the latest (also end-of-life for several years) firmware, and voila - the error was gone.

    I also know of some old changelogs for enterprise switches that had problems with DHCP relay. So maybe you should look for a changelog for the switch you are using and try to get a newer firmware.

    Of course it could also be a problem on the kernel side, but I suspect the number of home users with managed switches is not very large, to get a valid feedback from others.

    EDIT:
    Depending on the switch vendor you use, "trunk" implies that all traffic at this port is tagged. That means, you must ensure that the client (RPi) know about it and configure the corresponding VLAN ID there too.

    For the parameter „enable_uart=1“ is documented that this locks the clock rate as fixed, but as far as I know this is not true.

    enable_uart=1 NOT fixing core_freq to 250MHz · Issue #4123 · raspberrypi/linux
    Is this the right place for my bug report? I hope so, apologies if that's not the case. I've also posted on the RPi forum (See…
    github.com


    So since beginning I expected that the I2C speed could make trouble too, because of dynamic clocking. Perhaps this is unfounded for the I2C and only the RPi clock-stretching bug is an issue. Until now I couldn‘t verify that case.

    If you can catch a bad case again, please provide the full log, not only snippets. If my suspicion is right, then we will doesn‘t find a difference in the logs, because the issue exists only during transfer of the message at the I2C bus.

    To rule out this possible trouble maker we can try to set the clock rate manually. This will have some restrictions like:

    • higher power consumption, no clock down during idle
    • maybe shortening lifespan of the RPi4, because the clock should be set to 550Mhz to be fast enough for 4K

    By the way: I have also been trying out a different configuration without "enable_uart=1" for several months in order to use a different UART and not restrict dynamic clocking (if it after an kernel/firmware update accidentally works like designed ;)). This works too, if you can live without the integrated bluetooth adapter.

    I doesn‘t have a oscilloscope to see what happens at the I2C bus so I‘m not 💯 sure that could be the solution for the bad case scenario. For the I2C clock stretching bug, maybe slow down the I2C speed helps to mitigate the issue.

    I can’t imagine that the firmware has been corrected by Argon40. Also the shutdown should work, after you has confirmed via power menu. If there is no power cut after you triggered the shutdown via remote control, could also be an indication that the MCU is stuck.

    I know such behavior if there was send some (un)specific I2C messages for example with i2cdump command to the MCU before. If the MCU is stuck, mostly the fan runs permanently and long press (<= 5 seconds) of the power button doesn‘t work, only unplug of the PSU. <- this matches more to your description.

    Do you have some kind of overclocking active? Also other I2C devices/drivers maybe trigger this.