** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1754038
Title:
ARM M: Systick first wrap delayed (qemu-timers/icount prb?)
Status in
Now fixed in master, commit c52e7132d7c885, and will be in 2.12.0.
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1754038
Title:
ARM M:
Hi Peter,
I just tested your patch, I confirm it is also working on my side. Many
thanks.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1754038
Title:
ARM M: Systick first wrap delayed
Thanks for the test case; that was very useful. I've sent a patch which should
fix this bug:
https://patchwork.ozlabs.org/patch/895693/
The "writing a reload value smaller than the current counter" bug is one
of the ones I know about in our systick implementation. I may have time
to overhaul
** Tags added: arm
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1754038
Title:
ARM M: Systick first wrap delayed (qemu-timers/icount prb?)
Status in QEMU:
New
Bug description:
When running
The workaround I described above is actually not the good one, because
of this check occurring just before:
if (!all_cpu_threads_idle()) {
return;
}
The exit request setting must be done before, so my code looks like
this:
CPUState *cpu;
CPU_FOREACH(cpu) {
I finally implemented a workaround to correct the problem:
in cpus.c : qemu_start_warp_timer(), in the "if (deadline > 0) { ... }"
part, I added:
CPUState *cpu;
CPU_FOREACH(cpu) {
atomic_mb_set(>exit_request, 1);
}
I do not understand more than 5% of the code
Ok I spent more time trying to identify the commits giving problem.
So before 8d04fb5, qemu is executing the binary as expected:
setup timer
cnt 007a --7
cnt 006998a2 --7
cnt 00566479 --7
cnt 0043304f --7
cnt 002ffc26 --7
cnt 001cc7fd --7
Please find the binary attached.
I have been trying several versions and it looks like the regression
occured between v2.8.0 and v2.9.0.
** Attachment added: "Binary showing systick /timers/icount problem"
https://bugs.launchpad.net/qemu/+bug/1754038/+attachment/5072853/+files/hello.bin
--
OK, I will see if I can find some time to investigate this. Can you
attach your guest binary, please?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1754038
Title:
ARM M: Systick first wrap delayed
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
Delay between the counter hitting zero and the ISR firing is
architecturally permitted (the interrupt must be recognized in finite
time or at a context synchronizing event, but not necessarily at the
same 'clock tick' that the counter hits zero). If you want to ensure
that an interrupt has been
12 matches
Mail list logo
