[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] hw/char/cmsdk-apb-timer: Correctly identify and
Re: [Qemu-devel] [PATCH] hw/char/cmsdk-apb-timer: Correctly identify and set one-shot mode
Tue, 26 Jun 2018 19:10:45 +0100
On 26 June 2018 at 18:59, Guenter Roeck <address@hidden> wrote:
> On Tue, Jun 26, 2018 at 06:17:44PM +0100, Peter Maydell wrote:
>> Thanks for this patch. I was wondering whether it would be better
>> just to remove the fprintf message instead. I'll either apply
>> this or send a patch to do that before 3.0, anyway.
> If I recall correctly, I tried that, and it did not help.
> The messages don't happen too often, and the message itself
> does not cause a problem. Issue is that the interrupts happen
> at the wrong time or not at all (after a while, ie after the
> configured one-shot time expires), and the kernel really doesn't
> like that.
> I think the underlying problem was that the periodic timer counts
> the period down (based on the time set for the one-shot timer),
> stops with the "Timer with delta zero, disabling" message once
> the period reaches 0, and does not fire anymore afterwards.
> As a result, the kernel fails to boot maybe 90% of the time.
> I should probably have mentioned that in more detail in the
> commit log.
Hmm, that's odd, because I don't really see what the difference
between the two is. If you set the thing as a one-shot then we
won't reenable the timer later either with this patch.
Can you provide an image/QEMU command line that repros this,
and I'll see if I can find time to investigate it? (We have
a softfreeze deadline next Tuesday, so I probably won't be
able to get to it until after that, but since this is a bugfix
it doesn't have to be done before freeze.)
>> periodic timer if the reload register is written with a nonzero
>> value before the timer expires (and that if that happens after
>> the timer expired that we restart the timer). Thinking about
>> this is also on my todo list.
> I thought that was handled in the Linux driver by disabling
> the timer, updating the period, and then re-enabling it in
> periodic mode, but I may have misinterpreted the code.
Yeah, it would depend what the guest does whether it's affected,
but my reading of the data sheet is that messing with the reload
register with the timer still active isn't prohibited.