Meier

Members
  • Content Count

    17
  • Joined

  • Last visited

About Meier

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks for all the hints, will try this out. To be honest, I can't imagine to be the only one having these issues. Maybe it's just that our usage of the RockPro64 board with a PCIe NVMe M.2 SSD is not very common? We suspected the PCIe / SSD combination to be the cause for a long time, for but cannot really confirm this. The issues are consistent over dozens of RockPro64 boards and many SSD brands. And I've heard from users that the PinebookPro (which uses similar hardware) also freezes under heavy load when run with an SSD.
  2. This is a last-ditch effort to figure out how we can continue to build our project on top of Armbian. Goal We are building an appliance on the RockPro64 board, with eMMC and an PCIe SSD attached, using a custom-built Armbian Ubuntu 18.04 image with extensive post-configuration (packages, appliacations, overlayroot...) within the boot process. The image is then processed by Mender to create a true dual-root filesystem over-the-air update system with fallback (we invested a lot of resources to extend Mender for Armbian and RockPro64). This build process works perfectly and is ex
  3. I am experiencing frequent kernel panics with the RockPro64 board and assume it could be a power consumption issue with the SSD (PCIe NVMe M.2). I tested a variety of different SSDs, with the Cruzial P1 being the most reliable. Is it possible to manually throttle an SSD within Armbian, forcing it to consume less power? In my case, peak performance is not really important. This would allow me to further validate my thesis. Thanks in advance for any suggestions!
  4. Damn it, came in this morning and had the kerne freeze again on one machine. Talking of the devil... I took a picture of the screen (see attachment), but it does not really hint at what went wrong as far as I can tell. Even scrolling back didn't show much additional info. I'm a bit at a loss how to capture what actually went wrong... Any hints?
  5. Apologies, I did not really follow up on that issue as the following two measures prevented any further occurrences: Avoid using the mentioned Samsung SSD (currently using Cruzial P1) Run the eMMC as Ubuntu 18.04 with overlayroot enabled Not sure if it's both or only one measure, but no more freezes. Let's hope it stays that way.
  6. Thanks for the suggestions, will follow up shortly. First there's some vacations... :-)
  7. The boot failure is no longer an issue currently, after updating to Armbian Ubuntu 18.04 and using overlayroot, but the nvme spinlock keeps happening frequently. I noticed that it is mostly during intense writing to the SSD, which heats up, the system freezes and never comes back up. Strangely enough, the SSD is then still under constant load and does not cool down. I ran a dedicted stresstest with the tool stressdisk with the following script (it includes our own fancontrol tool): #!/bin/bash apt update -y apt install -y tmux unzip smartmontools mkdir src && cd $_ wget
  8. Thanks Myy for the pointers. I'll try if the dptx.bin driver helps preventing the boot oops message. Is there a way to tell how that binary file has been compiled, or to make sure it is legit? Regarding the stress testing in overlayroot, this command immediately aborts as it fills up the available tmpfs within seconds. Good thought about find /, I'll try that.
  9. Unfortunately, I still keep getting the freezes from time to time. Two thinks I noticed: When running `stress -i 4 -d 4` I can crash the board in ~3 minutes very reliably. But not any board, just this one, but even without any additional peripherals like the SSD plugged in. As it's running on eMMC, it might be this particular eMMC that causes the crash. This let me to build a latest Armbian Ubuntu 18.04 image with `overlayroot` to eliminate all I/O to the eMMC. This board that has been crashing has now been running for ~2 days. I'll try to gather more data in case the boards cr
  10. Thanks Igor! Will try that today and let you know how it works out. Update: works fine so far, after 3+ hours uptime, also with the self-compiled image, but intervals between freezes can be quite long.
  11. Additional info: after some quick uptime of ~1h the board started to fault repeatedly, but without crashing completely. SSH connections were closed, but later a login was possible again. Three specific errors in short interval, all logged in full here: https://pastebin.com/SAcUAGb2 Jul 8 16:59:31 carol kernel: [ 3752.234046] Unhandled fault: synchronous external abort (0x96000210) at 0xffffff8009d5401c Jul 8 16:59:31 carol kernel: [ 3752.240736] Internal error: : 96000210 [#1] SMP ... Jul 8 17:00:12 carol kernel: [ 3759.996389] BUG: spinlock lockup suspected on CPU#3, nvme/
  12. On several RockPro64 boards I experience infrequent freezes, mostly directly on boot, but also after some longer (hours, days) uptime. I use the official power adapter and no additional hardware except a PCIe adapter for an SSD, which works flawlessly when operational. When looking at the kern.log, there are quite a few errors and warnings, but comparing to a successful boot these are all also present. So I don't think they cause the freeze directly. Currently, I recorded the freeze on the latest Armbian Bionic as release just recently. FWIW, I think the same issue also
  13. Just wanted to let you know that we collaborated with Mender and Armbian for RockPro64 is now fully supported by the Mender.io open source client-server manager for over-the-air software updates. It should be relatively straight-forward to exend this approach to other boards as well. https://mender.io/ https://github.com/mendersoftware/mender-convert/pull/103
  14. I am looking to build a stable applicance that is updateable on demand / over-the-air in an atomic way. Ideally, it uses a dual-partition setup, where the is an active rootfs and an inactive one. On update, a new rootfs is streamed directly to the inactive partition, the device reboots to the new rootfs and - if everything runs according to plan - the new rootfs is committed as the new active one. If the reboot fails, the device reverts to the previous (still active) rootfs. This functionality is very common with embedded devices, many using the Yocto project. I'd like to try to us