Video Pauses - LE Reboots - Very Random

    I had all the skins and a dozen addons installed including several weather addons. I wanted to see the if RPi5 could do the heavy lifting of some of the skins. The Pi did not disappoint, but some of the skins did. And I cannot find a way to make the unwanted skins go away using the GUI.

    When I rebuild the RPi5 with an SD card, there will be no addons. I will certainly report back after the first unexplained reboot with a log file.

    After we are done testing in that mode and it's time to go back to the M.2, I'll put the better pcie cable in then.

    It's good that you hold some spare parts in the back hand. In the last months I have seen some log snippets with much more noise regarding this message:

    Code
    May 31 11:08:04.570436 RPi5a kernel: nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
May 31 11:08:04.570750 RPi5a kernel: nvme nvme0: Does your device have a faulty power saving mode enabled?
May 31 11:08:04.570864 RPi5a kernel: nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off" and report a bug
May 31 11:08:04.657093 RPi5a kernel: nvme 0000:01:00.0: enabling device (0000 -> 0002)
May 31 11:08:04.657277 RPi5a kernel: nvme nvme0: Shutdown timeout set to 8 seconds
May 31 11:08:04.660439 RPi5a kernel: nvme nvme0: 4/0/0 default/read/poll queues
May 31 11:08:04.670425 RPi5a kernel: nvme nvme0: Ignoring bogus Namespace Identifiers

    Yes, at normal desktop computer I wouldn't expect such messages regulary. But also NVMe firmware isn't free of issues. At the RPi5 I know about cases, that it could fixed, if they followed the recommendation and add this to the kernel line in the cmdline.txt.
    pcie_aspm=off
    Maybe you doesn't need another cable in your current configuration. But you should give it a shot, and check if it disappears after exchange the cabeling.

    I shut down the pi so I can take the m.2 board out. In the mean time I hooked the RockPro64 up and it is scanning in the changes in the library. Been moving a lot of stuff. When that is done, I will play tv episodes until the RockPro64 shows it's problem, and post that log.

    By then the RPi5 will be ready to fire up and we'll see if the problem persists without a m.2 HAT. If it does, we'll post that log. If it no longer shows the problem, then I'll add the "new" pcie cable and HAT, and perhaps try your command, although I am not sure where cmdline.txt exists.

    Quote from HarryH
    Code
    May 31 11:08:04.570436 RPi5a kernel: nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
May 31 11:08:04.570750 RPi5a kernel: nvme nvme0: Does your device have a faulty power saving mode enabled?
May 31 11:08:04.570864 RPi5a kernel: nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off" and report a bug
May 31 11:08:04.657093 RPi5a kernel: nvme 0000:01:00.0: enabling device (0000 -> 0002)
May 31 11:08:04.657277 RPi5a kernel: nvme nvme0: Shutdown timeout set to 8 seconds
May 31 11:08:04.660439 RPi5a kernel: nvme nvme0: 4/0/0 default/read/poll queues
May 31 11:08:04.670425 RPi5a kernel: nvme nvme0: Ignoring bogus Namespace Identifiers

    The dates in the log indicate it has had that error since Feb when it was new.

    I removed the pcie cable from the RPi5. M.2 is now neutered. It waits for the RockPro64 to fail, and then it's the Pi's turn.

    Edited once, last by WarpLover: Merged a post created by WarpLover into this post. (June 1, 2024 at 10:11 PM).

    You can find the file here: /flash/cmdline.txt

    Your Pi has no real-time clock, so the 2024-02-27 is the generated fake date during boot until it get a time synchronization via network. The kernel log messages are from your last startup (2024-05-31).

    Edited once, last by HarryH (June 2, 2024 at 8:49 AM).

    The problem has been found.

    I removed the pcie cable and did a fresh reinstall of LE wo/addons. It played 7 movies back to back overnight. I'd say that is stable.

    As you might have already guessed the user was the issue, but I need to put some of the blame on the Raspberry Pi Foundation.

    After ONE insertion of the PCIE cable, the connector on the Pi side is damaged. The moving lock down piece now comes completely out of the connector. And that connector does not look easily replaceable. The cable was obviously working and you could see the marks where the connectors made contact on the ribbon cable to each trace and on each end.

    I think about all the other connectors chosen for the PI and realize most of them are quality and will provide for hundreds of insertions, but not this jank-a-fied pcie connector. The Pi is a hobbyist board made for building and rebuilding, except for that connector (space constraints, I know). The geekworm connector looks even jankier but lasted through the first insertion. An old windows meme came to mind 'plug and pray'. I'm not left with a feeling of quality.

    It feels a little dishonorable, but I am going to see if I can return this Pi. I don't feel 100% at fault.

    Thanks for all of you who spoke up and helped. I hope this record helps someone in the future.

    I've learned a little about the logging system and that is certainly a plus. Man hugs ensue. $$$ Donation has been given.

    Now to look at the RockPro64.

    PS no use trying the other ribbon cable now.

    Edited once, last by WarpLover: added donation (June 2, 2024 at 6:20 PM).