piknew

  • Content Count

    95
  • Joined

  • Last visited

About piknew

  • Rank
    Advanced Member

Recent Profile Visitors

3067 profile views
  1. Please post dmesg output after changes are committed to emmc (with "w"). I had exactly the same issue - dmesg was reporting a lot of serious write errors. I already assumed that emmc is not usable anymore, however, after couple of weeks... I tried again and everything was OK. I am not sure if this was really hardware issue or software. So, please check dmesg output...
  2. piknew

    piknew

  3. I need to revert statement as above. My OPi+2E has "frozen". So, entry MIN_SPEED=408000 is not valid for my SBCs. Until it is corrected I have added following to /etc/cron.d/cpufrequtils-fix */5 * * * * root /bin/grep 'MIN_SPEED=408000' /etc/default/cpufrequtils 1>/dev/null 2>&1 && /bin/sed --in-place s/MIN_SPEED=408000/MIN_SPEED=480000/ /etc/default/cpufrequtils 1>/dev/null 2>&1 && /bin/systemctl restart cpufrequtils 1>/dev/null 2>&1 Edit. My mistake. It was that I have put my SBC on quite warm router. And during scheduled job
  4. It seems that with kernel 4.19.13-sunxi the typo is no longer causing issues (at least on OPi+2, which I've selected to perform test): ___ ____ _ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) _ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | |_| |_ | |_| | | | (_| | | | | (_| | __/ | __/| |_ _| \___/|_| \__,_|_| |_|\__, |\___| |_| |_| |_| |___/ Welcome to ARMBIAN 5.70 stable Debian GNU/Linux 9 (stretch) 4.19.13-sunxi System load: 2.25 1.43 0.62 Up time: 10 days Memory usage: 4 % of 2014MB IP: 192.16
  5. I will change it on one of my platforms to verify. It will be Orange Pi+ 2 - just a moment ago I have changed it back to original package version (with "408") and rebooted: ___ ____ _ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) _ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | |_| |_ | |_| | | | (_| | | | | (_| | __/ | __/| |_ _| \___/|_| \__,_|_| |_|\__, |\___| |_| |_| |_| |___/ Welcome to ARMBIAN 5.70 stable Debian GNU/Linux 9 (stretch) 4.19.13-sunxi System load: 1.43 0.34 0.11 Up time: 0 min Memory usage: 3
  6. @Igor, with latest upgrade the "typo" (408 vs 480) is still in cpufrequtils. Is there a chance (I mean: time to do it) to have it corrected in the source? THe related thread:
  7. Still OK (I can confirm this for all of my "orange" SBCs): [root@PKBACKUP ~]# date Mon Oct 29 20:21:27 CET 2018 [root@PKBACKUP ~]# uptime 20:21:32 up 8 days, 2:32, 1 user, load average: 0.10, 0.03, 0.01 [root@PKBACKUP ~]# ll /etc/default/cpufrequtils -r--r--r-- 1 root root 175 Oct 18 18:01 /etc/default/cpufrequtils [root@PKBACKUP ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=480000 MAX_SPEED=1296000 GOVERNOR=ondemand #GOVERNOR=performance [root@PKBACKUP ~]#
  8. After correcting cpufrequtils file - no issues so far: [root@PKBACKUP ~]# date Fri Oct 26 11:03:47 CEST 2018 [root@PKBACKUP ~]# uptime 11:03:53 up 4 days, 16:14, 1 user, load average: 0.00, 0.00, 0.00 [root@PKBACKUP ~]# ll /etc/default/cpufrequtils -r--r--r-- 1 root root 175 Oct 18 18:01 /etc/default/cpufrequtils [root@PKBACKUP ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=480000 MAX_SPEED=1296000 GOVERNOR=ondemand #GOVERNOR=performance [root@PKBACKUP ~]# Anybody else (who's SBC
  9. I referred to your post in: I guess the other thread is better to analyze this finding.
  10. For now I have modified cpufrequtils as following for my three boards (orangepipc, orangepiplus 2 GB, orangepiplus2e): [root@PKBACKUP ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=480000 MAX_SPEED=1296000 GOVERNOR=ondemand #GOVERNOR=performance For orangepizero as following: [root@PKOTHER ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=240000 MAX_SPEED=1200000 GOVERNOR=ondemand #GOVER
  11. Could you please take a look here: Considering that when running on performance mode - system seems to be stable but once switched to "ondemand" - unstable. May the "mismatch" be the root cause here?
  12. Could you please point out how to achieve this? All my H3 (also H2+) devices suffer from the issue as described. Even with newest kernel. So, after reading I decided to test stability with "constant cpu frequency". EDIT: I've done it by: [root@PKTEST ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=408000 MAX_SPEED=1296000 #GOVERNOR=ondemand GOVERNOR=performance [root@PKTEST ~]# Question: would it be possible not to overwrite cpufrequtils file once su
  13. SUCCESS Story: I have used armbian-config to check Hardware (if my I2C bus is enabled). I have noticed very strange behavior of function: grep was outputted in "usage" mode. I revieved all the scripts and it appeared that line which is searching for "overlays=" is throwing this error. My /boot/armbianEnv.txt didn't have any overlay, especially for I2C, enabled. So, I have added as following (+ overlay prefix): [root@PKTEST ~]# cat /boot/armbianEnv.txt rootdev=UUID=f8301761-6756-4f97-aa80-12c05ea037cf extraargs=pty.legacy_count=2 overlays=i2c0 i2c1 i2c2 user_overlays=ds1
  14. Definitely not (PKTEST is Orange Pi PC) - I also checked on OPI+2 with the same results (FAILED on "dev"). But I will try to downgrade to "next" on OPiPC (PKTEST). I will give an update in matter of minutes. Update: "next" is the same. But then I have downgraded to "Default" and: [root@PKTEST ~]# i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
  15. I am not sure if the path is correct - I used the one from dts file (in post above). It seems that "something" is there. However, I2C detect does not see any device under address 0x68. I am also not sure if aliases section of dts file will somehow override visibility of standard rtc0 device from SOC? Below are a few commands. [root@PKTEST /proc/device-tree/soc/i2c@1c2b000]# ll total 0 -r--r--r-- 1 root root 24 Oct 4 17:32 compatible -r--r--r-- 1 root root 8 Oct 4 17:32 clocks -r--r--r-- 1 root root 8 Oct 4 17:32 resets -r--r--r-- 1 root root 9 Oct 4 17:32 status -r--r--r