This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] recurring boot time scalability issues affecting time manage

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] recurring boot time scalability issues affecting time management
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Tue, 11 May 2010 07:59:14 +0100
Delivery-date: Mon, 10 May 2010 23:59:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
The patch titled "VT-d: prevent watchdog timer from kicking in when
initializing on systems with huge amounts of memory" submitted
yesterday, other than expected, fully fixed another late boot hang
(when Dom0 was almost fully up), i.e. apparently unrelated to issues
that may exist before Dom0 even gets started. There were no
indications of time problems in any of the logs, yet there must have
been such given that the boot hung without that change, but didn't
with it in place.

I wonder whether the time handling code in Xen itself shouldn't/can't
therefore be made more robust, or at least reliably detect this sort of
issue (from past analysis of similar problems, the platform timer is
rolling over due to there not being frequent enough invocations of
plt_overflow()) to make analysis of the problem easier.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>