* Isak Lichtenstein <Isak.Lichtenstein@xxxxxxxxxxx> [180216 13:36]: > We can imagine the following use cases that could trigger it: > - Another process stops the timer accidentally by clearing the ST bit of the TCLR register. > - Setting the ST bit of the TCLR register after loading the TCRR register goes wrong ( in omap2_gp_timer_set_next_event() ) e.g. interrupt, posted mode. Well there has been lost interrupt related issue for various drivers because of missing flush of posted writes. I doubt that is the issue here as the in that case the write ST bit should be set but written too late. If you have a test case for this, you could try the following hacks to try to narrow it down a bit more: 1. Set the clockevent timer to continuous mode instead of oneshot mode in omap2_gp_timer_set_next_event() This way if one interrupt is lost, the timer might trigger again although at n times the programmed length. 2. Add a read-back fo the timer register after programming it to omap2_gp_timer_set_next_event() This obviously will have a performance impact, but might give some clues. That being said, the same timer and the same interrupt controller hardware on a different SoC has users reporting uptimes of over 1000 days for Nokia N9 :) Sure yeah it's an older Linux kernel and it could be there is some am335x hardware issue or that we have a regression somewhere. Regards, Tony [0] https://talk.maemo.org/showpost.php?p=1541036&postcount=74 -- 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
