Part Number:AM3352
Tool/software: Linux
Hi, everyone.
I work on a customed board which is reference from BBB; during long time running test, the kernel will print like
this sometimes(if i open the CONFIG_DEBUG_TIMEKEEPING option in kernel):
[19407.204305] WARNING: Underflow in clocksource 'timer1' observed, time update ignored.
[19407.204311] Please report this, consider using a different clocksource, if possible.
[19407.204313] Your kernel is probably still fine.
then i trace the kernel, and found it is due to that the tmier1's cycle number which is readed by tk_clock_read in the timekeeping_get_delta is not correct. The following is the 'last' and 'now' cycle which the func timekeeping_get_delta got when the problem occur:
root@am335x-evm:~# [ 8450.894885] WARNING: Underflow in clocksource 'timer1' observed, time update ignored.
[ 8450.894891] Please report this, consider using a different clocksource, if possible.
[ 8450.894893] Your kernel is probably still fine.
[ 8450.894908] underflow_delta:4294826624, underflow_now:957480960, underflow_last:202821084544, underflow_mask:4294967295
[11198.954326] WARNING: Underflow in clocksource 'timer1' observed, time update ignored.
[11198.954331] Please report this, consider using a different clocksource, if possible.
[11198.954333] Your kernel is probably still fine.
[11198.954353] underflow_delta:4294588800, underflow_now:2486173696, underflow_last:268774524544, underflow_mask:4294967295
[14419.304466] WARNING: Underflow in clocksource 'timer1' observed, time update ignored.
[14419.304471] Please report this, consider using a different clocksource, if possible.
[14419.304473] Your kernel is probably still fine.
[14419.304491] underflow_delta:4294613950, underflow_now:2465202176, underflow_last:346062939202, underflow_mask:4294967295
it is obviously when the kernel call the func update_wall_time who use the timekeeping_get_delta to calculate the wall time, the dttimer1's cycle number it readed in this time(which is saved in variable 'now')and last time(which is saved in variable 'last') are abnormal; that make the problem happen. Once this happened, the application running on the board will be stuck if i do not open the CONFIG_DEBUG_TIMEKEEPING option in kernel.
I check the dttimer1's input clock source, it is the CLK_M_OSC ; which means the the dttimer1's clock source is the the external 24M crystal, so i use oscilloscope to measure the external 24M crystal, its frequency is stable and the jitter is very small, which is in line with our requirements.
On the other hand, on the BBB , this situation does not exist . So i compare the register configuration of dttimer1 between two boards, and found no difference between them.
because now i am using the RT-LINUX version on the boar,and this problem will make the task latency huge when i run the cyclictest(almost 12 ms in the worst); so i have to slove this problem.
Is anyone here can give me some clue to reslove this trouble? Whether in sdk-5.0(linux 4.14) or in sdk-4.0(linux 4.9),this problem exist.