• Content Count

  • Joined

  • Last visited

About AxelFoley

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. I have been monitoring the voltage and current draw of an individual RockPro64 on boot with the PCIe NVME Connected going to console. I then launched the desktop as both root (Armbian desktop) and pico user (looks like XFCE) and looked for any power spikes. There was none! Both tests caused a lockup and HW Freeze. On boot the peak current draw was 0.7A with 12v steady, and current draw dropping to 0.3A steady. Then I launched Xorg as root (in the past tended to be more stable) and user pico (always locked up immediately) I did notice a difference when I ran
  2. @TonyMac32 Thankfully I have the RockPro64 v2.1 board.
  3. @pfry Looking at the power Specifications for PCIe x 4 => Suggest that it can be powered from 3.3v (9.9W) & 12v (25W), however from the RockPro64 Power schema it looks like they negate to feed the 12v rail from the Supply voltage to the PCIe. Instead Pine feeds the PCIe Interface on the board only by the 3.3v (3A) rail (9.9W). From the Power schema It also looks like the board designers feed PCIe from the 5.1v rail converted by the RK808 PMU to 1.8v on vcc1v8_pcie (not sure how this is intended to be used on PCIe) I am using the Pine PCIe
  4. I think I have found the issue !!!!!!! Its the PCIe Express NVMe Card. I remove it and the desktop seems not to hang .... I add it back in .... and the desktop hangs. I wonder if this has something to do with power spikes when there is graphics activity the errors in the dmesg indicate that vpcie1v8 = 5.1v rail Shared with GPU vpcie0v9 = 3v Rail Both of these rails hang off the same core buck converter SY8113B, the other SY8113B manages the USB peripherals seperatly. @AndrewDB .... looks like you may be correct it was
  5. Interesting!!!! Fresh build on the spare EMMC64 Armbian_5.75_Rockpro64_Ubuntu_bionic_default_4.4.174_desktop.img created new user pico after changing the root password. The Device initiated nodm which initiated Xorg. Loaded the Armbian desktop ....... and hung immediately! HW Freeze and lock screen. Subsequent boots only boot to command-line with login prompt not desktop. /etc/default/nodem still has user root as default user to log in not pico. manually starting startx results in black screen of death as pico user (or on second try HW lockup s
  6. @balbes150 It for prototyping, education and engineering ... essentially enabling a quick and dirty evaluation of SOA (Service Oriented Architecture) concepts for myself and some other devs. e.g. NOSQL Databases and in particular how to integrate Service discovery and RDMA paradigm's such as the OFED stack (RoCE), and building restFul interfaces & API Abstraction while understanding principles such as standardized Data and message models. In essence to evangelize open source software and frameworks as a solution to proprietary software integration & inter-operation inertia.
  7. @AndrewDB apologies I missed the suggestion ... I disabled the HW Acceleration and restarted chrome from the terminal. Disabling the HW Acceleration stopped error messages being displayed in stdout. However the rockpro64 still locked up with a HW freeze loading the Armbian forum. But I think the whole graphics drivers on some of my cluster node have gone foo-bar for some reason. I may need to "apt install --reinstall [graphics subsystem packages] " to be sure that this is a bug not a missing library during interrupted apt update && apt upgrade
  8. Right I have now caught up with everybody's comments and questions and hopefully answered them. I now need some guidance on what to do next .... ### Hypothesis 1 ###: The root cause of the instability was a fundamental issue with the current Armbian code base (kernel/driver) and the rockpro64 4GB V2.1 + NVME + 64GB EMMC triggered by chromium loading the Armbian forum (100% reproducible) *** Action *** Continue to troubleshoot the unstable cluster master when using Chromium and figure out how to trap the HW Lockup when chromium launches the Armbian forum (nothi
  9. @chwe My bad .... to be fair ... every time I loaded the forum to post logs from the unit itself ... it chromium crashed the board :-) I did not release that armbianmonitor posted to a urlupload site ... smart ! See attached to the results from armbianmonitor -u
  10. @chwe Yes I have been working with the Pico Cluster guys to revise the power supply unit they ship with their cluster and we have upgraded it to a 12v unit instead of a 5V unit. I have also completely rewired the power cable loom and installed a buck converter for the 5v Switches and Fans. I have not gone to the extreme of checking individual output voltages and currents to the Boards from the PSU. But I have been monitoring the clusters total power consumption. The cluster is not loaded at all because I have not been able to do any work on it due to the stability of it. at peak it has ne
  11. @chwe A quick heads up .... people may not be aware but the pine guys have their own image installer based on Etcher that automatically pulls the Armbian image down without any indication of WIP or Stable status of the project (see attached). This is here Pine falls down a bit ... they should have focus on one main desktop & command line release to recommend to users ... if they are going to obscure project status from their installer. I only found out about WIP when I reported the issues. I have been testing several desktop imaged and to be fair to Armbian ... they
  12. see attached before crash, after crash and teh chromium error to the command line when launched from a terminal; I really don't care about chromium ,,,, when working on these boards I try to keep it as simple as possible and use stock packages in the hope I will have more bugs squashed. I am now using Firefox so I can at least start working on the GPIO code again. Thanks for the suggestions. It could be I need to run a debug kernel as I at least expected to see some issues there .... but the nature of the lockup could mean its a HW issue triggered in the
  13. @Da Alchemist that is a good point ... I made a rookie mistake thinking I could put up with a few glitches and still code. I then compounded it by using my cluster master as my development IDE, git master, salt master, Prometheus master, Grafana server.... its my own fault. I think its time to restart from scratch and move my code to github and reformat everything. I have clearly managed to bugger up the graphics mail drivers on the cluster Master/Dev box through continual upgrades and a link on the wiki to install HW accelerated mali drivers that are probably not feature complete.
  14. @NicoD Brilliant idea ..... I don't know why I did not think of that ... See attached ... I got those errors when 1st launching the Chromium browser. It works for a while as I navigate to the Armbian forum ... then locks up with no more command line output. Interesting that it goes back to my hunch this was a graphics driver issue causing the instability. Its just strange that Chromium triggers the issue but not firefox!
  15. armbian-config does not do a good job of installing lightdm, it failed to launch lightdm on boot with errors around trying to restart the service too quickly after it initially failed to start. I don't have time to troubleshoot somebody else's sloppy mess. I have reverted back to nodm so I can get back to writing some code. The display lockup when nodm boots and logs in as any other user apart from root ... is not going to be nodm's problem I suspect. more likely an Xorg config issue \ graphics driver. good to know I can avoid 90% of my stability i