Problem with CPU under-clocking in Odroid HC1

    • OMV 4.x
    • Problem with CPU under-clocking in Odroid HC1

      Hey

      Can anyone confirm the problem with under-clocking in Odroid HC1 with OMV 4.1.17.1, Kernel 4.19.14, Armbian 5.70?

      I could always reach 2000/1500Mhz without a problem. Currently, after the last Armbian update from 5.60 to 5.70, I noticed a strange behavior that HC1 does not want to reach full clocks. With cpufrequtils min 600 max 2000 and "performance" and clocks do not want to go higher than 1800/1300Mhz temperature cpu 45.0 ° C.
      No changes just last updates nothing more was touched. Any suggestions?

      After returning to 5.60 and 4.14.69 the CPU runs normally at 2000/1500 ....
      I also have the impression that HDD sometimes behaves strangely at 5.70 / 4.19.14



      @tkaiser

      The post was edited 2 times, last by JohnStiles ().

    • JohnStiles wrote:

      Any suggestions?

      Only to keep discussions about low-level hardware stuff with ARM boards where they (should) belong to... Armbian forum: forum.armbian.com/topic/9277-p…id-hc1-hints-appreciated/

      Most probably device-tree with the new kernel version defines different cpufreq/DVFS operating points and this got undetected (Armbian still supports way too many boards. Quantity vs. quality and one of the usual results).
    • JohnStiles wrote:

      clocks do not want to go higher than 1800/1300Mhz
      BTW: For everything OMV/NAS related this is pretty fine. You won't get higher NAS transfer rates at 2000/1500 MHz. Only higher consumption and temperatures. Also the performance difference is less than 10% which is not noticeable in general.

      But I agree: should be fixed, so better report your findings where it can be fixed (Armbian and not OMV).
    • tkaiser wrote:

      JohnStiles wrote:

      Any suggestions?
      Only to keep discussions about low-level hardware stuff with ARM boards where they (should) belong to... Armbian forum: forum.armbian.com/topic/9277-p…id-hc1-hints-appreciated/

      Most probably device-tree with the new kernel version defines different cpufreq/DVFS operating points and this got undetected (Armbian still supports way too many boards. Quantity vs. quality and one of the usual results).

      tkaiser wrote:

      JohnStiles wrote:

      clocks do not want to go higher than 1800/1300Mhz
      BTW: For everything OMV/NAS related this is pretty fine. You won't get higher NAS transfer rates at 2000/1500 MHz. Only higher consumption and temperatures. Also the performance difference is less than 10% which is not noticeable in general.
      But I agree: should be fixed, so better report your findings where it can be fixed (Armbian and not OMV).

      I asked here because I use omv. ARM images are based on armbian ... not my choice. :)
      I thought that maybe as a person present on both sides of the projects you will be able to move something forward a bit. Because the armbian forum I feel is quite often insensitive to the reported problems.
      Maybe it is not a problem for the NAS itself, but if someone uses the system for something more, it may be a bit ...


      You say that there is no OMV problem. Ok maybe not omv itself, but it does apply to ARM images for xu4 / hc1 / hc2. which you can download. You can of course say that it is completely unofficial and not supported in that case it would be nice to write to let every user know before downloading and installing.


      I probably write on the armbian forum, I just need to set up an account there first.
      But looking at the url you gave me, I'm not the first and no one seems to care.
    • JohnStiles wrote:

      But looking at the url you gave me, I'm not the first and no one seems to care

      As already said: Quantity vs. quality.

      BTW: there's more than just lower CPU clockspeeds. Cloudshell 2 users when updating will loose the TFT display: forum.armbian.com/topic/9340-o…d-after-upgrade-to-41914/ -- no idea what other surprises come with next apt update.

      Since I've also no idea why switching from a known working kernel branch to an unknown state was 'needed' I thought I ask: github.com/armbian/build/commi…62#commitcomment-31979374
    • tkaiser wrote:

      JohnStiles wrote:

      But looking at the url you gave me, I'm not the first and no one seems to care
      As already said: Quantity vs. quality.

      BTW: there's more than just lower CPU clockspeeds. Cloudshell 2 users when updating will loose the TFT display: forum.armbian.com/topic/9340-o…d-after-upgrade-to-41914/ -- no idea what other surprises come with next apt update.

      Since I've also no idea why switching from a known working kernel branch to an unknown state was 'needed' I thought I ask: github.com/armbian/build/commi…62#commitcomment-31979374

      So I wrote on the forum ...
      The only thing Igor advises is to go back to 4.14.y because 4.19.y is not polished for xu4.

      Only in that case, if someone is aware that 4.19 requires polishing for xu4 then why would anyone push it ....
      The whole 4.19.y looks pretty unfinished for xu4

      I am currently sitting on 4.14.87 Does armbian have anything newer than 87 for xu4 from 4.14?
    • JohnStiles wrote:

      if someone is aware that 4.19 requires polishing for xu4 then why would anyone push it

      Ask Igor. I got pretty tired of dealing with these issues again and again. I mean... I use Debian (AKA 'everything outdated as hell') for just one single reason: the 'stable' promise. But what do I gain from a distro that is stable (Debian) when kernel and bootloader updates (Armbian) constantly cause pain? It simply makes no sense at all.
    • tkaiser wrote:

      Ask Igor. I got pretty tired of dealing with these issues again and again. I mean... I use Debian (AKA 'everything outdated as hell') for just one single reason: the 'stable' promise. But what do I gain from a distro that is stable (Debian) when kernel and bootloader updates (Armbian) constantly cause pain? It simply makes no sense at all.

      I can ask but I will not get an answer. :)
      If you dev's are not able to somehow work out a compromise, it's not good ....

      Until now, somehow I did not have a bigger "but" to armbian, but lately something like going uphill.
      Debian .... real middle ages. I used to always choose Debian, but this prehistory is slowly bothering me.


      Maybe you have plans for some drastic changes?