From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: KVM virtual timer issue with trinity
Date: Fri, 11 Oct 2013 18:23:56 +0100 [thread overview]
Message-ID: <5258342C.9080903@arm.com> (raw)
In-Reply-To: <20131011171750.GF5108@cbox>
On 11/10/13 18:17, Christoffer Dall wrote:
> On Wed, Oct 09, 2013 at 12:00:39PM +0100, Will Deacon wrote:
>> On Thu, Sep 12, 2013 at 04:27:16PM +0100, Christoffer Dall wrote:
>>> On Thu, Sep 12, 2013 at 10:37:50AM +0100, Will Deacon wrote:
>>>> On Fri, Sep 06, 2013 at 05:30:52PM +0100, Will Deacon wrote:
>>>>> Running trinity as a normal user in a KVM guest on my TC2 (A15s only)
>>>>> eventually leads to a situation where responsiveness is extremely sluggish.
>>>>> Further investigation shows that issuing a `sleep 1' command never returns.
>>>>> This seems to be because the virtual timer has stopped generating interrupts
>>>>> on CPU0 (CPU1 seems ok).
>>>>>
>>>>> Dumping the timer state (see below), it looks like CPU0's timer expired in
>>>>> the past, but we're perhaps not receiving the interrupt. The trinity logs
>>>>> don't reveal anything obvious (and they're huge, so I can't include them
>>>>> here).
>>>>>
>>>>> I can reproduce this in an hour or so, so if you want me to try anything out
>>>>> in the host, I can give it a go. I'm using 3.11 as both the guest and host.
>>>>
>>>> Any ideas on things I can do to get to the bottom of this? It's preventing
>>>> me from running trinity to find any other issues and there's no reason you
>>>> couldn't hit this lockup under other workloads.
>>>>
>>> I've been thinking on this, sorry about the late response.
>>>
>>> I see something similar when resuming a suspended guest, but I don't
>>> have very clever ideas or debug strategies yet. I plan on looking at
>>> this once I get a new revision of the save/restore QEMU patches out.
>>
>> Marc was saying that you'd managed to resolve the issue with suspend, but I
>> can still reproduce the issue with trinity on a 3.12-rc4 kernel (host and
>> guest).
>
> Yeah, that issue turned out to be simply overwriting the restored
> counter values. I need to look at this some more, still present in my
> todo list...
>
>>
>> I tried to reproduce in a model, but I ran into a bunch of other unrelated
>> problems that look like bugs in the model itself.
>>
> Great...
I have a TC2 running, trying to catch the sucker. Haven't observed it
yet after a day, very annoying.
M.
--
Jazz is not dead. It just smells funny...
prev parent reply other threads:[~2013-10-11 17:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-06 16:30 KVM virtual timer issue with trinity Will Deacon
2013-09-12 9:37 ` Will Deacon
2013-09-12 15:27 ` Christoffer Dall
2013-10-09 11:00 ` Will Deacon
2013-10-11 17:17 ` Christoffer Dall
2013-10-11 17:23 ` Marc Zyngier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5258342C.9080903@arm.com \
--to=marc.zyngier@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.