Comment 2 for bug 1754038

I tried to insert an ISB in the loop but I get more or less the same result.

However, I guess from your response that I did not explain the problem well enough. I understand that qemu will not be cycle accurate, however, here, we are not even "one million cycles accurate"! The counter would have the time to wrap twice before qemu is taking into account the first ISR... and if we check the following ISR time, we have a good accuracy, so I still think this is a bug.

Morever, as said above, if I test with qemu 2.5.0 from Ubuntu package I get an accurate behavior:

setup timer
cnt 00799997 -- 7
cnt 0063323b -- 7
cnt 004ccade -- 7
cnt 00366383 -- 7
cnt 001ffc26 -- 7
cnt 000994ca -- 7
SysTick
cnt 00832d5e -- 10007
cnt 006cc5eb -- 7
cnt 00565e8f -- 7
cnt 003ff733 -- 7
cnt 00298fd7 -- 7
cnt 0013287b -- 7
SysTick
cnt 008cc108 -- 10007
cnt 00765996 -- 7
cnt 005ff239 -- 7
cnt 00498add -- 7
cnt 00332381 -- 7
cnt 001cbc24 -- 7
cnt 000654c8 -- 7
SysTick
cnt 007fed5c -- 10007
cnt 006985ea -- 7
cnt 00531e8d -- 7
cnt 003cb731 -- 7
cnt 00264fd5 -- 7
cnt 000fe879 -- 7
SysTick
cnt 0089810c -- 10007
cnt 0073199a -- 7
cnt 005cb23d -- 7
[...]

So here I would suspect either a regression in the code or a wrong combination of options when I compile it myself. I am trying to recompile version 2.5 myself to sort this out but I am running in other errors.