Message-Id: <4D94862E02000078000395D0@vpn.id2.novell.com>
Date: Thu, 31 Mar 2011 12:48:30 +0100
From: "Jan Beulich" <JBeulich@novell.com>
To: "Martin Wilck" <mwilck@arcor.de>, "Jinsong Liu" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Cc: "Donald D Dugger" <donald.d.dugger@intel.com>,
	"Gang Wei" <gang.wei@intel.com>,"Xin Li" <xin.li@intel.com>,
	"Yunhong Jiang" <yunhong.jiang@intel.com>
Subject: Re: [Xen-devel] Re: system freeze when processor.ko is loaded
	during boot
References: <4CAF794F.6070308@arcor.de>
	<4CBEAEE2020000780001E237@vpn.id2.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E1E7146599A@shsmsx502.ccr.corp.intel.com>
	<4D910C24.5090908@arcor.de> <4D911044.8000306@arcor.de>
In-Reply-To: <4D911044.8000306@arcor.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 29.03.11 at 00:48, Martin Wilck <mwilck@arcor.de> wrote:
> Here is one more capture. It shows that (unfortunately) clocksource=3Dpit=

> doesn't help here, and that the xen watchdog hits if I configure it
> (just that the reboot doesn't work, and I can only see the output since
> I've been using the serial console).

The stack evaluates to=20

logarithmic_accumulation
update_wall_time
do_timer(0x898d7)
tick_do_update_jiffies64
tick_sched_timer
__run_hrtimer
hrtimer_interrupt
timer_interrupt

(matches the previously sent one, just that there the tick count
passed to do_timer() is "only" 0x179ab.

So the kernel, afaict, is busy recovering from the time jump in Xen.

It is clearly also a bad sign that the NMI hit while Dom0 was
executing, as that guarantees interrupts aren't disabled (and
hence timer interrupts can occur, and timers would not be
prevented from running - presumably the time jump suppressed
the invocation of, among others, the NMI timer).

Jan