Re: [Qemu-devel] Broken Microblaze timer

[Peter Crosthwaite]

On Fri, Jun 15, 2012 at 8:39 AM, Peter Chubb <address@hidden> wrote:
>>>>>> "Paolo" == Paolo Bonzini <address@hidden> writes:
>
> Paolo> Il 14/06/2012 04:29, Peter Crosthwaite ha scritto:
>>> Obviously this sucks as a patch, but without this hack, the system
>>> freezes on boot. I managed to ascertain that its coming from the
>>> ptimer used by the system timer (hw/xilinx_timer.c). The CPU is
>>> either halted and never resumes, or the timer is flooding with halt
>>> requests and the CPU never gets another look in.
>>>
>>> The question is, is this a failure in ptimer, xilinx_timer or the
>>> async framework? Can ptimer be misused such that the CPU is locked
>>> up?
>
> Paolo> Yes, this looks like the ptimer is flooding the iothread so
> Paolo> that the CPU does not get an occasion to run.
>
> Paolo> Perhaps you want to limit the rate of the hw/xilinx_timer.c to
> Paolo> something like 1000 Hz or something like that.
>
> Changeset cf36b31db209a261ee3bc2737e788e1ced0a1bec Limit ptimer rate
> to something achievable
> is meant to fix this in the cases where the timer is auto-reloaded.
>
> xilinx_timer.c always uses the timer in one-shot mode, so it needs to
> be fixed in there.
>

So ptimer has safeguards against misuse in periodic mode but not
one-shot mode? This strikes me as inconsistent. I.E. for one use case
the safeguard is in ptimer, and the other in the client device. I
think if we are in the bussiness of putting these safeguards in ptimer
itself then it should be there for all use cases yes? I.E. the fix for
this is making sure one-shot ptimer give the cpu a look in.

Regards,
Peter

>
>
> --
> Dr Peter Chubb                                  peter.chubb AT nicta.com.au
> http://www.ssrg.nicta.com.au          Software Systems Research Group/NICTA