qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Bligh <alex@alex.org.uk>
To: Xiexiangyou <xiexiangyou@huawei.com>,
	Matthew Anderson <matthewa@base3.com.au>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	qemu-devel@nongnu.org, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle
Date: Tue, 22 Oct 2013 10:35:52 +0100	[thread overview]
Message-ID: <3CFE968397006BAF41FA4D5C@nimrod.local> (raw)
In-Reply-To: <7A2C95E1327F7148AB122F200A3EFA403447D838@SZXEMA502-MBX.china.huawei.com>



--On 22 October 2013 08:28:08 +0000 Xiexiangyou <xiexiangyou@huawei.com> 
wrote:

> Hi:
>
> I have run windows2008r2 guest with qemu-1.5.1/1.6(I have not test the
> the newer  version) for long time, the issue (guest in hangup state) will
> come out.When guest  in hangup state, QEMU main thread is blocked in
> g_poll loop.
>> 398c398,399
>> <     uint32_t timeout = UINT32_MAX;
>> ---
>>>     /* uint32_t timeout = UINT32_MAX; */
>>>     uint32_t timeout = 1000;
>>
> It seems can fix the problem, and rtc/hpet interrupt can inject into
> guest again  because of the "timeout", and guest will wake up . But maybe
> the issue is also exist,  because during the time before timeout , guest
> also will lose rtc/hpet ticks.

I do not think that is the correct fix for 1.5.1/1.6; what you
are basically doing is limiting the wait in the mainloop to one
second (1.5.1/1.6 are in milliseconds); however, I believe there
may be other code that looks for infinite timeouts. Either there
is some other bug that this is masking (in which case it may
or may not be fixed in master / 1.7), or its a bug in the timer
stuff in 1.5.1/1.6 (which would not surprise me) which is likely
to have been fixed in master / 1.7.

-- 
Alex Bligh

  reply	other threads:[~2013-10-22  9:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-08  9:38 [Qemu-devel] BUG: RTC issue when Windows guest is idle Xiexiangyou
2013-10-16 14:56 ` Matthew Anderson
2013-10-21 14:56   ` Alex Bligh
2013-10-21 15:13     ` Alex Bligh
2013-10-22  8:28     ` Xiexiangyou
2013-10-22  9:35       ` Alex Bligh [this message]
2013-10-28  6:58         ` Matthew Anderson
2013-10-28  7:44           ` Alex Bligh
2013-10-28  8:46             ` Alex Bligh
2013-10-30  0:44             ` Xiexiangyou
2013-10-30  7:23               ` Alex Bligh
2013-10-28 11:51           ` Paolo Bonzini
2013-10-30  1:29           ` Xiexiangyou
2013-10-30  7:26             ` Alex Bligh
     [not found] <5C390CF7F373CC4AB58A6684FF6C8712013DD0E2@Exchange2010-2.corit.local>
     [not found] ` <20130221222246.GH10005@vm>
2013-03-14  4:15   ` Matthew Anderson
2013-03-19 17:53     ` Gleb Natapov

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=3CFE968397006BAF41FA4D5C@nimrod.local \
    --to=alex@alex.org.uk \
    --cc=matthewa@base3.com.au \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=xiexiangyou@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).