After analyzing several +30945 seconds leaps, using the coLinux debug version, I managed to solved the mystery.
The root cause of the problem is a timer read hardware glitch.
The glitch occurs when the 24th bit of the counter should overflow, but it doesn't.
Instead of reading 0x16242A000004, a value of 0x162429000004 was read.
Instead of reading 0x13510E000005, a value of 0x13510D000005 was read.
This causes an error of -4.68 seconds (for a 3579545 frequency).
The code in callback_return_jiffies(), together with an inaccuracy in co_div64() causes some interesting results:
The first time the glitch occurs the time leaps forward by 24 seconds.
When subsequent glitches occur, time will leap forward by 30945 and 30956 seconds alternatively.
The results can be verified with the simulation below.
It seems this clock reading problem is well known and there are several workaroun ds for it.
For example see the the thread http://email@example.com/msg34826.html and http://support.microsoft.com/kb/274323 .
In any case, I think that a simple check to verify that clock did not shift backward from previous read is a must.
In addition, if the clock changed more than a threshold, then the clock should be read again in loop until below threshold.