Based on tglx's suggestion, I ran the following test on 2 panda boards.
>
> clock_gettime(CLOCK_MONOTONIC, &prev);
> while (1) {
> clock_gettime(CLOCK_MONOTONIC, &curr);
> if (curr < prev) /* Use a proper compare function for
> timespec! */
> printf(.....);
> prev = curr;
> }
Both of them fail this simple test with vanilla (both single core and
SMP) kernels (2.6.39-rc4 mainline with high-resolution timer patch,
3.0.1 mainline with high-resolution timer patch, 3.1-rc2 OMAP git tree
without any patch but with high-resolution timer enabled) within a few
seconds to an hour. Time goes backwards from as low as 234 nsec to 53
usec. The problem does not reproduce without high resolution timer
(i.e by enabling 32 KHz timer in kernel config) for several hours of
testing.
Is this issue panda board specific or a common issue on all ARM
targets? Is it a known issue already and anyone looking into it?
Thanks in advance for the help,
Sankara
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
