> On Apr 28, 2016, at 5:44 AM, John Syne <john3909@xxxxxxxxx> wrote: > > > >> On Apr 28, 2016, at 1:14 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: >> >> On Wed, 27 Apr 2016, John Syne wrote: >> >>> I’m attempting to add DMA support to the ti_am335x_adc driver but when >>> running the Lauterback debugger, I get strange timer corruption and the >>> kernel completely loops forever in include/linux/math64.h and takes the >>> “bhi” branch below and never gets to C00BB2A0. >> >>> So here is what I see after single stepping and running and stopping several >>> times. As you can see, the timer is negative and this is causing a lockup. I >>> have seen the same occur with timekeeping_get_ns where delta is negative ( >>> tkr->cycle_last occurs after cycle_now) . Seems like a race condition. Does >> >> It's not a race condition. By stopping the kernel you make the clocksource >> wrap around resulting in a negative delta. > That makes sense, however it seems that clocksource wraps every 172 seconds, which doesn’t make sense to me. Given a 32 bit number, I would expect clocksource to wrap every 2,147 seconds. What am I missing? >> >>> anyone have any idea as to why this would be happening, or alternatively, >>> how can I just cleanup this up when I get a negative value. I tried setting >>> tkr->cycle_last = cycle_now, but that didn’t work. >> >> Enabling CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE should fix that issue. > Thanks Thomas. I’ll give that a try. I see that CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE is only defined for x86 in that it is included in arch/x86/Kconfig. Cannot select it with make xconfig My guess is I can do the same with arch/arm/Kconfig and add select CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE in config ARM section. Does that sound correct? Regards, John > > Regards, > John >> >> Thanks, >> >> tglx -- 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
