Adrian Cable

  • Content Count

  • Joined

  • Last visited

About Adrian Cable

  • Rank

Recent Profile Visitors

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

  1. Alexis - this looks to be like a "normal" (non-LTS) board. I think your CPU temperature really is around 73 degrees, which sounds normal to me for 100% load on 4 cores. For me, on the LTS board, in the same scenario, I get a reading around 40000 (i.e. 40 degrees C). Unless I've misunderstood, I think an offset is (at least roughly) enough.
  2. What's the correct reporting to channel to get this into the queue to get worked around in Armbian? I understand that the "root cause" is probably on the board side, but we do have a number that increases monotonically with temperature and should be usable once we figure out the slope and offset. Great for everyone's feedback on this issue here, but it isn't clear if this forum gets the issue in front of the right eyes to be addressed in a future version of Armbian. Does anyone know how this process works?
  3. Interesting. Now what would be nice is if we could set an offset of 27 degrees C at runtime. I note that there is: /sys/devices/virtual/thermal/thermal_zone0/offset However something like this seems to have no effect: echo 27000 > /sys/devices/virtual/thermal/thermal_zone0/offset; cat /sys/devices/virtual/thermal/thermal_zone0/temp Any ideas what the correct syntax is and/or if writing to offset has any effect? -Adrian
  4. @yoq - this is extremely interesting - thanks for your work on this. It seems that there is an offset of about 27 degrees C that needs to be applied on the LTS boards. Of course, I guess we don't know the slope is right either, but from my own experiments it seems that the error is simply an offset. The next problem is that I'm not sure how we can detect that the OPi Zero board we're running on is an LTS board, and adjust the offset parameter accordingly. All the boards return a HW string of 'Xunlong Orange Pi Zero' whether they are LTS or not. Do you know how/if it's possible to detect this in software, and then adjust the returned offset? I suppose this would need to be implemented in sun8i_thermal.c. -Adrian
  5. @Craig St George - it is confusing because both the LTS and non-LTS boards have the same screenprinting on the PCB (Orange Pi Zero 1.4 or 1.5). The temperature read-out is correct for the non-LTS boards, but broken on the LTS boards. Looking at /etc/armbianmonitor/datasources/soctemp, it seems to be an offset problem. The LTS boards under-read by somewhere between 30 and 40 degrees C. I'm not sure what the correct channel to report this is, so the Armbian devs can look into it. Not sure if posting in this forum gets this issue in front of the right eyes or not.
  6. @Werner - are you saying that you get correct thermal readouts with armbianmonitor on OPi Zero LTS? I definitely don't! Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 11:21:33: 480MHz 0.05 8% 4% 4% 0% 0% 0% -737°C 0/4 11:21:38: 480MHz 0.05 8% 4% 3% 0% 0% 0% -495°C 0/4 11:21:43: 480MHz 0.04 6% 4% 2% 0% 0% 0% 2.2°C 0/4 11:21:49: 480MHz 0.04 7% 4% 2% 0% 0% 0% 474°C 0/4 11:21:54: 480MHz 0.04 8% 4% 3% 0% 0% 0% -11°C 0/4 11:21:59: 480MHz 0.03 7% 3% 3% 0% 0% 0% 2.4°C 0/4 Everything works fine for me with the non-LTS boards. -Adrian
  7. Hi - I can also confirm that the thermal readout is broken on OPi Zero LTS, for all kernels (4.19.62, 5.3.x, 5.4.x). If anyone has found a fix, please share! -Adrian
  8. Hi, I'm having issues with an unreliable HW watchdog on the Orange Pi Zero. I am using the standard Armbian kernels (tried 4.19.62, 5.3.x, 5.4.x - all the same) and have nowayout=1: [ 4.328286] sunxi-wdt 1c20ca0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=1) I'm feeding /dev/watchdog every 2 seconds. Superficially it works, for example, if I do the following the WD triggers after 16 sec and the board reboots: echo c > /proc/sysrq-trigger However I am finding that in other crash scenarios, the WD reboot sometimes happens and sometimes does not. For example, with a forkbomb :(){ :|:& };: about 70% of the time the WD reboots the board, but 30% of the time the board stays crashed and the WD never reboots it. (I've confirmed that the forkbomb does stop the watchdog feeder, so the WD should trigger a reset.) I have to do a hard power cycle to get it to boot again. Has anyone else had experience with an unreliable watchdog on these boards? Any more insight or fixes? -Adrian
  9. Yes - 5.4.1-sunxi # gives the same problem. Happy to stick with 4.19.x @Werner, but I have some OPi Zero LTS boards on the way, and my understanding is that the thermal sensor doesn't work with 4.19.62, but does work with 5.4.1. Is that correct? -Adrian
  10. @dolphs - actually this is the "original" (non-LTS) OPi Zero. I believe I tried 5.4.x and had the same issue, but will double check. -Adrian
  11. Hi, Using the latest Armbian release (19.11.3) on OPi Zero (512MB, board revision 1.5) I have a strange issue. On kernel 5.3.x, Ethernet connectivity drops sporadically, around once every couple of minutes, for typically 10 seconds or so and then recovers. When the drop happens, a ping from another machine on the network produces 'no route to host' - then after around 10 seconds or so the network comes back up. The OPi Zero continues running normally during the 'outage', without functional network access. There is nothing in the dmesg log when this happens. Switching to kernel 4.19.62 from armbian-config, everything works perfectly. Back to 5.3.x, the issue starts again. Has anyone seen a similar issue and/or has a fix? Thank you! -Adrian