From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60165) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYYNk-0003k5-GW for qemu-devel@nongnu.org; Tue, 22 Oct 2013 05:36:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYYNi-0001fL-VK for qemu-devel@nongnu.org; Tue, 22 Oct 2013 05:36:08 -0400 Received: from mail.avalus.com ([2001:41c8:10:1dd::10]:47584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYYNi-0001ez-Ow for qemu-devel@nongnu.org; Tue, 22 Oct 2013 05:36:06 -0400 Date: Tue, 22 Oct 2013 10:35:52 +0100 From: Alex Bligh Message-ID: <3CFE968397006BAF41FA4D5C@nimrod.local> In-Reply-To: <7A2C95E1327F7148AB122F200A3EFA403447D838@SZXEMA502-MBX.china.huawei.com> References: <7A2C95E1327F7148AB122F200A3EFA403447B128@SZXEMA502-MBX.china.huawei.com> <08BFF9FD34CF37498327C2B6102BDD1E20009F07@Exchange2010-2.corit.local> <157A2E8C7A89F4CBD37C2DD5@nimrod.local> <7A2C95E1327F7148AB122F200A3EFA403447D838@SZXEMA502-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle Reply-To: Alex Bligh List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xiexiangyou , Matthew Anderson Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, Alex Bligh --On 22 October 2013 08:28:08 +0000 Xiexiangyou 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