Heisath

Ok I will test and measure the consumation. Do you plan to really fix the drifting in a future release or just wait for an upstream fix?

Morning, I just tested your changes zador, and the time is working properly once again! Now also ntp is synchronising etc... Many thanks! One thing though, because with cpufreq ondemand my clearfog was running at 666MHz at about 90% of the time... So now the consume would have about doubled. As "The dynamic power (switching power) dissipated per unit of time by a chip is C·V²·A·f, where C is the capacitance being switched per clock cycle, V is voltage, A is the Activity Factor[3] indicating the average number of switching events undergone by the transistors in the chip (as a unitless quantity) and f is the switching frequency." (Wikipedia) So now I have to decide if I'd rather use ntpdate + hwclock every few minutes or let the clearfog run at full speed the hole time :/ If I were to re-enable dfs, I only would have to take the files out from the disable_dfs folder and copy them one layer higher, correct? https://github.com/armbian/build/tree/master/patch/kernel/mvebu-next Greetings, count-doku Btw. just donated, grab yourself a beer, awesome work!

I read the thread posted by zador and it seems like this is exactly the problem. After checking the A38x Marvell Fu-Spec. I would say the A388 also has SSCG. See the A38x-Functional-Spec-PU0A.pdf at https://marvellcorp.wufoo.com/forms/marvell-armada-38x-functional-specifications/ (or reupped https://jannis.imserv.org/nextcloud/index.php/s/y39mH3eA6D4jTRI ) On page 65 it says that there is SSCG functionality.

Oh I did not expect you to fix this in the next kernel. I am already amazed that the support for armbian is so much better than from the solid run guys. Take your time! For reproducing the bug, just take your images: https://dl.armbian.com/clearfogpro/archive/Armbian_5.38_Clearfogpro_Debian_stretch_default_4.4.112.7z https://dl.armbian.com/clearfogpro/archive/Armbian_5.38_Clearfogpro_Debian_stretch_next_4.14.14.7z burn them onto an sd card an try: :> date --set "07 FEB 10:11:13" :> hwclock --systohc :> timedatectl Repeat the timedatectl after a minute or so and you can already see the drift... Is it possible to tell the armbian ./compile.sh to use the new 4.15.y Kernel? Then I would try this myself. Yesterday it selected 4.14.y for next and dev options. Greetings, count-doku

Hi, thanks for the fast reply. I have tested with clean images from https://dl.armbian.com/clearfogpro/archive/ and can confirm that it is a bug in the "stretch next" 4.14.(14) Kernel. The "stretch default" image 4.4.112 contains a working systemclock. Whew am I relieved that my board aint broken. Is it possible to fix this in the next kernel? Edit: I will try to build the 4.15.y kernel and update. Check if this already fixes the issue Edit Edit: Updated to 4.14.17 problem still persist. Couldn't get a build with 4.15.y Greetings, count-doku

Hi, I have a problem with my ClearfogPro, it worked fine for some time but now theres something wrong with the system clock and I am unsure wether this is caused by the hardware or software. I set the time with the date command, then copy it to the rtc with hwclock --systohc... After a few moments the times in sys/hw are already a few seconds apart. The system clock seems to be about 1/3 second to slow.... So after a few minutes its completely off, this causes ntp to stop working ofc. I tried fixing this by using adjtimex but the setable value range ist not large enough... This is the output of timedatectl ca 5 seconds after doing hwclock --hctosys Local time: Tue 2018-02-06 19:52:37 CET Universal time: Tue 2018-02-06 18:52:37 UTC RTC time: Tue 2018-02-06 18:52:44 The RTC is pretty accurate btw. But the system time keeps lagging behind.. I also tried a clean armbian image, but the problem persists. For the moment I fixed this by using crontab to copy the hw time to systime every 5minutes but this can't be the solution. Is this a bug in the current builds oder rather a hardware problem? Greetings, count-doku