Clock shift with high CPU load

It just happened again while compiling kernel:

make[2]: Warning: File `sound/soc/msm/built-in.o' has modification time 67 s in the future
  LD      sound/soc/snd-soc-core.o
  CC      fs/jbd/commit.o
  LD      sound/soc/built-in.o
make[2]: Warnung: Mit der Uhr stimmt etwas nicht. 
Die Bearbeitung könnte unvollständig sein.
make[1]: Warning: File `sound/soc/built-in.o' has modification time 67 s in the future

Memory:

$ free
             total       used       free     shared    buffers     cached
Mem:        828696     801012      27684          0         56     178680
-/+ buffers/cache:     622276     206420
Swap:      1676480     136928    1539552

Anyway, the CPU should never be able to block the clock I think? At least I never saw something like this before on other hardware. Isn't a busy CPU exactly why a clock source exists (like hpet/tsc on desktop) ?

I see the Jolla Smartphone using "gp timer". Google tells this is a "general purpose timer" and most likely builded into the SoC. Anyway, there should be other timers available, like from the watchdog or, according to kernel docs, from the CPU:

        clocksource=    Override the default clocksource
                        Format: <string>
                        Override the default clocksource and use the clocksource
                        with the name specified.
                        Some clocksource names to choose from, depending on
                        the platform:
                        [all] jiffies (this is the base, fallback clocksource)
                        [ACPI] acpi_pm
                        [ARM] imx_timer1,OSTS,netx_timer,mpu_timer2,
                                pxa_timer,timer3,32k_counter,timer0_1
                        [AVR32] avr32
                        [X86-32] pit,hpet,tsc;
                                scx200_hrt on Geode; cyclone on IBM x440
                        [MIPS] MIPS
                        [PARISC] cr16
                        [S390] tod
                        [SH] SuperH
                        [SPARC64] tick
                        [X86-64] hpet,tsc</string>

So I would love to test other clock sources but don't know how to change kernel command line. Does anyone know? I really need this fixed ASAP.

//EDIT:

# cat /sys/devices/system/clocksource/clocksource0/available_clocksource 
gp_timer dg_timer
# echo dg_timer > /sys/devices/system/clocksource/clocksource0/current_clocksource

And the system crashes. So we have one clock source crashing the device and another one not being accurate. Now where are imx_timer1, OSTS, netx_timer, mpu_timer2, pxa_timer, timer3, 32k_counter and timer0_1 ? And, even more important: How to fix the clock?

//EDIT²: If that matters: With dg_timer the system doesn't crash immidiately. The UI freezes immediately but by switching the clocksource back (via ssh) it unfreezes again. I guess the real crash happens when the watchdog kicks in cause everything is frozen.

//EDIT³: "Now where are imx_timer1, OSTS, netx_timer, mpu_timer2, pxa_timer, timer3, 32k_counter and timer0_1" - To answer my own question: Not enabled in kernel config: # CONFIG_ARM_ARCH_TIMER is not set. So no way to fix without recompiling kernel, which is on my todo list but fixing clock has way higher priority... Kind of chicken-egg problem now... Help?

compilation flags and parameters??

@Claudio Maradonna 3 threads (make -j3) and compilation flags... Whatever the default Jolla kernel uses. Anyhow, that doesn't really matter. Kernel compilation is just a good way to trigger this bug but there are others (android gaming and basically everything with high CPU load).

//EDIT: Experiencing this bug on 1.1.6.27 and 1.1.7.24 - older versions untested.